Universal InfraRed Transceiver support [Archive]

Mark F

October 13th, 2002, 03:55 PM

Thanks. I have a bunch of plugin code that uses overlapped IO for serial communications. I've already looked at your code and it is well documented so this should be pretty straight forward.

As for my previous question: "How hard would it be to modify this design to use an external IR sensor and transmitter block?"

I have a couple of problems and proposed solutions I'm trying to tie together.

My first problem is I have the equipment to be controlled inside a fully enclosed closet (no line-of sight) so I thought adding IR emitters via connecting blocks would be an easy way to extend the reach to the equipment on the different shelves.

The second problem may not be a real problem. I want to place the receiver right below the screen in my theater. It cannot look "bad". I don't get to define what "bad" means. My wife does. If the receiver looks "bad" I will need to replace the receiver with one that cannot be seen or looks better. (maybe this (http://smarthome.com/8108.html) one)

Of course, I'm open to alternative ideas for making this work with my "conditions".

Thanks, again.

Mark F

October 13th, 2002, 03:55 PM

Thanks for the "heads-up". If/when I get one of these and get the software working, I'll have to modify it with a connector (3.5mm plug) or two. :smile:

Mark F

October 13th, 2002, 03:55 PM

WOO HOO!!!! Bring it, baby!!!!!

I will be ready by Tuesday as Monday is a holiday. :smile:

Mark F

October 13th, 2002, 03:55 PM

Some remotes, and the equipment they control, do that (rotate codes). If you have a few remotes laying around, I'd suggest trying a couple of them to see if all of your remotes do it or just one or two.

EDIT: Scratch that. What you are describing is REALLY weird. Sorry.
_________________
Mark F

[ This Message was edited by: Mark F on 2001-08-29 20:28 ]

Mark F

October 13th, 2002, 03:55 PM

When my UIRT arrives, I'll test it with the same remote. Since this one learns, what remote did you teach it with? Or are you using the RC5 code set? Thanks.

Mark F

October 13th, 2002, 03:55 PM

I'm working on it. :smile:

Right now I can't seem to get the same button to produce the same command reliably. The commands are variable length (depending on the remote control) and the values vary between pressing the same button twice. This is NOT the rolling code feature. It could be a sample rate problem or something else. I've got a dozen or so remotes here so I'll see if I can find ONE that is more repetative. If not, I'll have to put in some heuristics. :sad:

I'll let you know how this progresses.

Mark F

October 13th, 2002, 03:55 PM

I've sent some E-Mail to Ruud's Hotmail account about some of the problems I'm seeing. The .dll source code he provides doesn't match the data that I'm receiving from the device.

Mark F

October 13th, 2002, 03:55 PM

I'm trying to get the "T" portion working but am running into some problems. The worst problem is the received data doesn't match the data structure. According to all the documents and the provided source code, the received data is SUPPOSED to be 21 bytes in size, every time. It is not. Still no response from Ruud.

Mark F

October 13th, 2002, 03:55 PM

Still no word from Ruud. Seems like support isn't what UIRT is all about. I guess I'm spoiled by Girder. :smile:

I hope to find more time to work on this but have hit a busy point at work. I may get a day off in a couple of weeks. :sad:

Mark F

October 13th, 2002, 03:55 PM

I'm very interested, too. This is GREAT! :grin: :grin: :grin:

I'll have to figure out how to download PIC code into the UIRT. Do you think the modified PIC serial code will still work on the 10Mhz UIRT design? Or could you port your fixes back onto the original PIC code?

Mark F

October 13th, 2002, 03:55 PM

If these changes make the UIRT more robust, or, in my case, make it possible to transmit at all, I'd like to use them. Thanks. :grin:

Mark F

October 13th, 2002, 03:55 PM

PLEASE get a real device code from Ron and publish your plugin on this site!

Ingo

October 13th, 2002, 03:55 PM

Hi Mark,

do you have the same problems while using the original program? The receiver's data sheet recomends two additional elements. A capacitor and a resistor. A guy who's working at the same place as I do told me to add these two, because the receiver wouldn't work to good without these as the power supply needs to be absolutely stable. (no, I didn't start building my own, still waiting for some more success stories, and planing to add some switching functionality)

Ingo

Ingo

October 13th, 2002, 03:55 PM

Hi,

I've had a similar idea some time ago.... using the now unused outputports as switchable pins. This would make it possible to switch an amplifier, TV, ....
I've allready redone the PCB design using EAGLE (still needs some doublechecking and possibly some changes (I still don't know how to switch high power devices.... any hints?))

Ingo

Ingo

October 13th, 2002, 03:55 PM

genixia,

Can you post the Eagle files somewhere and I'll take a look.

thanks, I've sent you a private mail on this. doesn't make much sense to post it as long as it's not proven to be ok.

As regards the high power switching, it could be done with a Triac or a Silicon Controlled Rectifier, or easier, a relay.

I know about relays... but I don't know how to attach them to the pic ;-(

However, I think that you'd be best advised to leave this board only dealing with CMOS level outputs, and let the end user worry about interfacing to higher voltages. There are devices commercially available that will switch higher voltages based upon a low voltage trigger, and it's just not worth the risk of litigation should someone-else use your design and get fried because of it!

hm, good point.

For my use, and many other girder users, X10 is the way to deal with switching high voltages. It's COTS technology with a proven track record. Plus, girder supports X10 wonderfully via serial->x10 interfaces.

that would be a great option... unfortunately X10 stuff is hard to get in Germany and way to expensive (around $40 for one switch).
So at least for me and for the moment this is just a nono. Building a cheap relay-board would make much more sense.

Ingo

October 13th, 2002, 03:55 PM

Jediperry,

and also because I was unaware whether the PIC had run-tiem programmable flash onboard.

as far as I read the datasheet, the pic contains a flashable area that is intended for program code and can be written around 1000 times (I think its size is 512 words, 14 bits each). There is an additional serial programable eeprom of 68 bytes. It can be programed a lot more (I think it was 100.000 times)

Ingo

October 13th, 2002, 03:55 PM

jon,

sounds great, but what do you think about adding support for controlling all these four I/O lines from the pc?

Ingo

October 13th, 2002, 03:55 PM

genixia,

when doing the i/o line controll from the pc side there's no need to do it with the same codes as from the ir side. Probably it would be best to add a special code start character that would only be used for line switching. This shouldn't add too much latency to the pic's code on normal operation.

Ingo

October 13th, 2002, 03:55 PM

On 2001-10-18 17:32, Robin wrote:
Or have I missed something obvious ?

yes, wake on ring doesn't work by sending 'RING' to the serial port, but toggling the RI-line (ring indicator).
This still shouldn't be too much of a problem as long as it starts the pc from soft-off mode, which I didn't test yet, but I don't think it's going to work this way.

Ingo

[ This Message was edited by: ingo on 2001-10-18 18:45 ]

Ingo

October 13th, 2002, 03:55 PM

Hi Jon, genexia,

this all sounds great.
As for the output pins... driving relays would be a great option :wink: ...
and for the two sepparated IR outputs, how about adding an option to drive them independently, selected by girder? this would allow to drive two devices reacting on the same code by directly attaching the LEDs to the IR-receivers. (just an idea)

jediperry

October 13th, 2002, 03:55 PM

universal infrared transceiver (http://people.a2000.nl/rwvgesse/FixFrame.htm?Uirt.htm)

I have also been collecting the bits together. I should have one made by the end of the week. I am only half way through learning c++ at the moment so I'll let someone more experienced do this one :smile:
I may give it a go anyway as a learning experience but like Ron says don't hold your breath.

jediperry

October 13th, 2002, 03:55 PM

Nice idea.

1) If we wanted to be really fancy we could right a version that could be told to learn an ir code for switch on. This would require the use of a pic with some flash.
I've not looked at the code for this yet, how much space is actualy left on the pic?

2) There is always a way :smile:

3) Pics are designed to be low power. If it can be powered from the serial port safely it can't consume that much. The more adventurous could consider tapping the low current 5v that is always supplied by atx psu's.

4) its either to ground or 5V, either way a fet will work.

Mike

jediperry

October 13th, 2002, 03:55 PM

I would have thought it most likely that each io bit will be controlling different devices so it would be best to be able to control one bit at a time.

Mike

jediperry

October 13th, 2002, 03:55 PM

I think the wol/power switch question could be left to the individual user as they both work the same (has anyone discovered whether the power switch connects the line to gnd or 5v?). The wol connector would be preferable with its 5v supply (2 birds with 1 stone).

Robin..
The only benifit of using flash that i can think of is for people that choose not to go for the battery back up option will still be able to do a remote switch on after a power cut. Or was the pic flash memory non-volatile, its such a long time since I've used the things.

Mike

jediperry

October 13th, 2002, 03:55 PM

... why use flash memory when the purpose of this device demands that it has constant power ?

Sorry, my last reply was rather badly worded. storing the codes in some registers makes it essential that power is maintained else it will be forgotten. Using the flash mem, allows for the power to be interupted (power cut or what ever) and the power on function will still operate afterwards.

Can't we develop an attachment that solves both (all three ) cases ?

Yeah, I think thats inevitable anyway :grin:
I recon if anyone wanted to be really cheap, they could get away with connecting the pic io pin directly to the power switch or wol, They are most likely ttl logic inputs with a weak pull down to gnd. But as genixia says, its probably a good idea to put some buffering inbetween.

Mike

(Of cource i take no responsibility if people blow their mobo's doing the above :smile: )

[ This Message was edited by: jediperry on 2001-10-18 23:00 ]

jediperry

October 13th, 2002, 03:55 PM

Have you had any success in interfacing a pic uart to a pc uart without a max232 or some extra descrete circuitry in between them. If I remember rightly, the pic uart is an inverted ttl interface. I tried it a couple of years ago but failed to get it to work without a max232. Maybe I was just unlucky and the pc had an unforgiving uart :???:

Personaly I prefer the 16f77, it has virtually everything you could possibly want except usb. :wink:

Mike

jediperry

October 13th, 2002, 03:55 PM

OK, just bodged together a test circuit, using U24MHZ10.HEX 1.1a.
The 4 IO pins work fine although I havn't got round to connecting them to anything yet. The wol header is the next step but I need to buy a buffer chip tomorrow.
AS for TX, no success yet. I am only running it from the dtr line at the moment so its probably just not getting enough power.

My only suggestion at the moment, although I am not sure how it could be best implemented, is an option for girder to block the control of an IO pin once booted. i.e. it would be nice to be able to use the power button on my remote for other things without turning the pc off again. :grin: (Although, now I think about it, this probably won't be an issue if wol is used (?))

Mike

[ This Message was edited by: jediperry on 2001-10-28 18:40 ]

jediperry

October 13th, 2002, 03:55 PM

Mike, I just hacked a web page together with my current schematic so you can take a look at how I'm intending to do things. It includes a buffer chip (ULD2003A - 7x open collector logic drive darlington, fairly easily available and low cost).
If you don't need in-circuit PIC programming, the FET can be removed, and MCLR driven from RTS via a resistor with zener clamps...

Let us know what you think..

Thats just about what I have. Is there a reason for cts to be connected to RxD?

Also, what is the purpose of the rts line controlling MCLR in normal opperation? If it does serve a purpose then the fet can't be removed or, as Jon said, the pic will not function when the pc is powed off. Otherwise, the MCLR line could just be tied to the +5 line.

I assume that RB0 is being an input to trigger a girder event.

Mike.

Hmm, I seem to have run out of system resources, "canvas does not allow" appently. :sad:. I think thats the first time girder has crashed for me.

jediperry

October 13th, 2002, 03:55 PM

Just to let you know, I will hopefully get time to test the 10MHz code on Sunday. Maybe even get the thing hooked up to the wol connector.

Cheers
Mike.

Eelector

October 13th, 2002, 03:55 PM

Jon.
I would very much like to see some pictures of your "proto-board"! I haven't got any etching equipment så this is my only choice. It would be a great help to see the finished layout (the one with no onboard programming and +5v from PSU).
I'm using the board model with "stripes" of copper, but i guess that won't matter. Just a little more work. :smile:

EDIT: Will a 2N3704 transistor work instead of a 2N3904?

[ This Message was edited by: Eelector on 2002-01-22 18:12 ]

[ This Message was edited by: eelector on 2002-01-22 20:02 ]

Eelector

October 13th, 2002, 03:55 PM

Can anyone please tell me the MINIMAL configuration for a UIRT (4mhz version) need to get the girder plugin to detect it (the green dot).
Im having problems with my UIRT and cant seem to find out thats wrong.

Would +5v and ground to the pic (no caps), RDX and TDX lines with the 10k resistor and a resonator be enough for the plugin to detect it?

Im using Jon's 1.6-hexfile.

[ This Message was edited by: Eelector on 2002-02-01 21:51 ]

[ This Message was edited by: Eelector on 2002-02-01 21:55 ]

oe1k

October 13th, 2002, 03:55 PM

So, who's working or willing to start working on a Girder driver so we can send on this $10 wonder?
I'm currently shopping for the parts to make some up, hopefully within a month I'll have a few working.

My first project will be to make the pc board to solder the componants to. Since it's not much more work to make 8 than it is to make 4, I'll have plenty extra.

If any potential developers would like, I'm willing to send you the pc board for the cost of shipping (and you can get the parts), or I'll make you the whole thing for the cost of parts and shipping (~$US15 I'm guessing).

Who's interested or already started?
_________________
-Richard L. Owens

[ This Message was edited by: oe1k on 2001-07-20 23:23 ]

oe1k

October 13th, 2002, 03:55 PM

Great! Right now, the professor on campus that knows how to do the board etching hasn't been in, so it migt be a while.

What's the "AVS Forum"? Sound like something I should start reading...

oe1k

October 13th, 2002, 03:55 PM

Another person in the AVS Forum is also offering to build a few of these. He and I have exchanged E-Mails already. For me, having more than one would allow me to make the software more robust.
Bad news: Craig (the other guy from avsforum) and I are now working together, so I doubt there'll be any difference between the built UIRT's.
Right now, it looks like the parts will cost around $10, before the cost of
the PCB and shipping.
This dousn't count the cable and serial plug (I'm cutting the "tails" off some old mice for mine.)
Any more takers before we order the parts hopefully later this week?

oe1k

October 13th, 2002, 03:55 PM

I'm just ready to order the parts today (so I haven't tested them yet), but the part you want is the PIC16F84-10/P, but the PIC16F84-10I/P will work (the 'I' just means that the chip is designed to handle higher temperatures, but will probably be more expensive than the PIC16F84-10/P).
The part after the '/' is what type of package the chip is built in:
/P means is has pins to go thru the PCB
/SO means is is built to solder on top of a PCB (Surface Only - surface mount version)
So, PIC16F84-10/P aught to be the part we want.
PIC16F84-04 won't work because that's the 4MHz version and we will be running at 10MHz.
I'm getting the parts from newark.com, and I'll be getting the PIC16F84-20/P ($5.02 each) since it is cheaper than the PIC16F84-10/P (don't know why) and works at any speed up to 20MHz, so it should work fine at 10MHz.

Also, I'm using the TSOP1738 ($1.36 each) from newark.com for the IR receiver. This has a base frequency of 38KHz, and should work great still for remotes at 36KHz and 40KHz.

oe1k

October 13th, 2002, 03:55 PM

Well, here is my current parts list from newark.com: Keep in mind that there are lots of parts that would work, these are just the cheapest I could find
Newark-# Manufacturer-# Unit Price ($US)
12C1942 PIC16F84A-20/P 5.02
Cheapest price I've seen yet. digikey.com has them for 6.00 for less
than 25 units, 3.69 each for 25-100, but I'm not getting that many.
95B4865 TSOP1738 1.36
The larger type IR receiver.
95B4858 TSAL6200 0.35
IR-LEDs: Slightly more expensive than the ones from digikey, but these
were suggested by Ruud's page.
06F1739 BS170 0.19
Transistor as suggested by Ruud
95B4971 1N4148 0.02
Small signal diode, same one Ruud suggested. Nice price too.
09F4064 1N5231B 0.07
500mW 5.1V zener diode.
09F4128 1N5243B 0.29
500mW 13V zener diode.

18C1529 XT49U10M 0.46
A 2-wire 10MHz crystal. Cheap.

Also:
Resistors and capasitors (I'm getting them from the Electrical Engineering
lab here on campus at Uni), and the jumper blocks and shunts I'm recyling
from dead PC parts (the come off pretty clean).

oe1k

October 13th, 2002, 03:55 PM

Re-looking over the schematics, I'm still pretty sure that you've got the pins wrong on your IR receiver, but we wont know for sure until either Ruud (the creator) responds to my email or one of us actually gets a UIRT working.
My first try has the same problem as yours: gives the error programming after like 99%.
I'm going to try and double-check my connections, but I can't get into the electronics lab to use the equipment (I need to buy a multimeter).

oe1k

October 13th, 2002, 03:55 PM

Yes, I looked at your mark-up, and now I see where you get your info from:
I think that Ruud made a typo on the pin-number labels on his schematic.
If you look at the schematic and trace the "Vcc" (pin 14 on the PIC) line, it goes to "pin 3", but should be pin 2 ("Vcc" on the SFH506 style pinout).
Vcc on the board should definantly NOT be connected to the data OUT pin on the receiver, right? Vcc does look like it should be connected to the data-in RB3 (pin 9 of the PIC).
I think he labeled pins 2 and 3 wrong.

I emailed you a copy of the older UIRPROG.EXE that I archived a month ago.
Tell me if it helpd.

oe1k

October 13th, 2002, 03:55 PM

I just got home and tested the old UIRPROG.EXE, and it worked!
My pin-out receives great!
(Now to go test IR sending, then post everyone their kits).
Thanks for the suggestiong on trying the older program!

oe1k

October 13th, 2002, 03:55 PM

Sending by replacing the irdll32.dll in VirtualRemote with the one he provides works - a bit touchy on the number of messages sent, but looks good.
Just install VirtualRemote (http://www.virtualremote.co.uk/) and replace the irdll32.dll, then set the "Parallel Port" setting in the program to the number of the Com port you are using (1 or 2) and right-click on a button to program it.
MarkF, you should be getting your UIRT by Monday. I hope you are ready! :wink:

oe1k

October 13th, 2002, 03:55 PM

On 2001-08-29 19:46, DP wrote:
Hello,
If someone have problems with programming UIRT it can check http://student.math.hr/~dpticar/uirt.htm , I have puted there uirt programmer, Its for 4mhz versions buz should work with 10mhz (I think).

bye

I looked at the test program, but it wouldn't test in UIRT mode: it says that the UIRT didn't respond with "OG", but the specs on Ruud's site say that the UIRT should repond with "RO" in native mode! What version of "UIRT" (with a 4MHz clock?) was this written for?

oe1k

October 13th, 2002, 03:55 PM

I just added a local link of VirtualRemote to my UIRT building page at http://www.ida.net/users/oe1k/uirt/uirt.htm

_________________
-Richard L. Owens

[ This Message was edited by: oe1k on 2001-09-06 18:09 ]

oe1k

October 13th, 2002, 03:55 PM

With receiving on the UIRT, I have one remote (a JVC old VCR remote) that doesn't read the same code hardly at all, but my RadioShack universal remote reads flawlessly. Anyone have an easy way to figure what frequency a remote uses? From the data I've read around, I understand that 1) "most" remotes use 38KHz (which is why I was happy to use the 38KHz receivers in my UIRT kits), and 2) the only other frequencies used are 36.67KHz or 40KHz.
I'd be interested to know what this JVC remote uses, so that I can understand why the UIRT doesn't read it consistantly (I assume it is using 36 or 40, but could it be further off than that?)

As far as the extra capacitor and resistor: I don't have the courage to modify the design, and it seems to work perfect with this RadioShack remote, so I'm already happy. But, if someone else does look into modifying the design, share!

ACClarke

October 13th, 2002, 03:55 PM

I'm very interested in it !!
because in france 10 mhz pic is much more expensive than de 4mhz

ACClarke

October 13th, 2002, 03:55 PM

thanks a lot !!

ACClarke

October 13th, 2002, 03:55 PM

Please could you send me the modified .asm ??
I would like to add a led and a PC wake up (with external power) and to do this I need this files.
And thanks again for your great job !!

ACClarke

October 13th, 2002, 03:55 PM

add RC5 code is a great idea but with my 4mhz uirt your girder plugin doesn't work.
could you solve my problem ??

ACClarke

October 13th, 2002, 03:55 PM

i know it's not compatible , it's my problem
my remote is an RC5 one and it doesn't work with your version of the uirt firmware

ACClarke

October 13th, 2002, 03:55 PM

Your girder plugin work well with my jvc and my sony remote but not with my "pc" remote which is an Akai.
with this remote I reiceive nothing in girder but with virtualremote I receive very well!
I don't understand why !
but i see that the other girder plugin for uirt can reiceive 2 different code
standard or standard and RC5, that's why I try it, but it doesn't work with the 4mhz version.

ACClarke

October 13th, 2002, 03:55 PM

1.yes

2.i use U24mhz4.hex and only this one

3.I use a 4MHZ PIC (16f84a/04)

ACClarke

October 13th, 2002, 03:55 PM

i can't see the lenght of virtualremote codes i don't know where it's stored

when i use uirt plugin in girder with my akai remote , nothing appears!
I can read GirderOpen :smile: and only that

ACClarke

October 13th, 2002, 03:55 PM

It doesn't work
it's not a big problem , I will find another remote !
thanks for the help
and for your great job

ACClarke

October 13th, 2002, 03:55 PM

hi
Danijel_Pticar : I try to use your new 4mhz firmware (1.2) and your girder plugin but it says ERROR-no 'OK' UIRT reply
but when i use uirt-test it receive very well.
I use a different hardware than uirt (same pic configuration but no IN circuit programming) I also use RXD and TXD to receive and transmit.
Do you use any other com pin ???

ACClarke

October 13th, 2002, 03:55 PM

here is my hardware configuration
http://www.multimania.com/acclarke/uirt1684.gif

ACClarke

October 13th, 2002, 03:55 PM

Danijel_Pticar
I find my problem, it's a "hardware problem" but you can help me if you add a option to pull up DTR pin in your girder plugin.

but I can also use an external power.

Wykat

October 13th, 2002, 03:55 PM

Mark,

I've build an UIRT and replaced the on board transmitting LED's with a connector so I could use an extention cable. I Believe the same can be done with the receiving part, but making a SMD version of the PCB could be a more elegant way with the receiver and PIC on opposite sites of the board.

rgrds,
Wykat

Wykat

October 13th, 2002, 03:55 PM

I have a working UIRT build according the schematics from Ruud. It works great with my HTPC with only 1 small limitation and that's the fact that the UIRT receives also the commands from my IR keyboard. The original UIR didn't do that. Maybe it's possible to get some delay in Girder after pressing learn. Now it always takes an IR keyboard command.

I've not yet used the T part. How to have this function added to Girder soon.

Wykat.

Wykat

October 13th, 2002, 03:55 PM

Same question for me. I already have a 10 MHz UIRT ready.

rgrds,
Wykat

Wykat

October 13th, 2002, 03:55 PM

thx,

does this mean however that I have to relearn all functions with my present RC?

Ron, would it be possible to have some delay after 'LEARN'. I'm using a remote keyboard but Girder takes immediately the left mouse press as learned IR code.

rgrds,
Wykat

a happy Girder user :wink:

Wykat

October 13th, 2002, 03:55 PM

Help, I can't get the new software to work. I programmed with U24.hex (and also tried the timeout verstion), but after programming the UIRT doesn't work anymore. Also the test option in Ruud programming application claims no response.

Will reinstall the original firmware again.

Wykat

Wykat

October 13th, 2002, 03:55 PM

Panic now. When trying to reinstall the original firmware; Error writing config word.

Wykat

October 13th, 2002, 03:55 PM

Solved :wink:

Tried to program on 3 different computers (Dual Celeron 466, Athlon 1.4 and AMD-K6@350) all running W2K and none of them was capable to write the PIC again. Finally used an old notebook with W98 and now the new SW is working.

Strangely enough Ruud's firmware gave me an error msg while writing, the new software not.

So new firmware is now installed and working. Will have to start learning new codes now.

Wykat

Wykat

October 13th, 2002, 03:55 PM

Can someone confirm that the transmitter part work? UIRT does work now and I'm able to define signals to transmit, but somehow can't get that part to work.

I do see with a normal DC voltage meter some activity on the LEDs, but none of my A/V equipment reacts to it.

On Ruud's page he mentions to use 950 nM IR leds. In the Conrad manual 880 nM are offered for remote control applications. Which one is better? (Problem is 950 nM are 7mW and 880 >30mW)

Wykat

Wykat

October 13th, 2002, 03:55 PM

Hi,

I'm using the U24.hex (for the 10 MHz version). From your reply I understand that the different carrier settings must be changed before learning. Is that correct? I have only tried different carriers after I had learned a code.

For the rest everything is working properly again. It is hard to imagine to use my HTPC without a normal remote control anymore :wink: Therefor I was really shocked when I couldn't reprogram the PIC on my W2K machines.

I also would like to thank you for making the transmitting part to work within Girder.

rgrds,
Wykat

Wykat

October 13th, 2002, 03:55 PM

Ingo,

Jediperry's idea is not to switch power, but to use a parallel switch to the power on button (If I understood correctly).

For your purpose there are electronic relais, able to switch >100A. I've used those myself to control a heater (1000 W), but I have no experience what kind of influence they have on AV equipment.

rgrds,
Wykat

ps thanks for working on a solution :wink: Power on is at the moment the only thing missing. Could you make a SMD PCB ? this keeps the receiver small.

Wykat

October 13th, 2002, 03:55 PM

@Jon Rhees: ideally the parallel power on button should have 2 functions;

1) Power on (short press)

2) Power off (5 second hold)

Further a reset function would be usefull, although it should be well 'hidden' on the remote control.

rgrds,
Wykat

Wykat

October 13th, 2002, 03:55 PM

I do have an original build UIRT but I'm not yet using the new software. I'm waiting for a new PCB design with IO control :wink: .

hope that will come soon.

rgrds,
Wykat

Wykat

October 13th, 2002, 03:55 PM

Hi,

personally I would prefer SMD due to its size. I've once made a dual sided SMD PCB myself and with a small solder iron I could build it. Never tried a heat gun. The only problem I discovered are the connections between the 2 sides. When you make a PCB yourself it's very difficult to have through hole connections under SMD parts.

With SMD components on both sides however the PCB can become very small.

rgrds,
Wykat

P.s. ever thought of combining it with a LCD/LED solution like http://www.cadsoft.de/people/kls/vdr/remote.htm ?

Wykat

October 13th, 2002, 03:55 PM

I'm using a 10MHz UIRT (original Ruud design) for several months now and also experience sometimes the "can't read 1st character". This happens when I reboot W2K. When I shutdown and then power up again, this failure doesn't appear.

Wykat

Wykat

October 13th, 2002, 03:55 PM

I've tried to follow the discussion but somewhere I got lost. Can somebody make a summary with the latest schematics, PCB lay-out and firmware ?

I think that would help many people after 10 pages :wink: .

Wykat

Ruud

October 13th, 2002, 03:55 PM

Hi all,

Well I am of course willing to write a driver for Girder, but frankly I am not so familiar with the program, So u just tell me which functions the plugin (DLL) should be able to perform and I will write it. Or perhaps even better :smile: someone who works with Girder can write a DLL (with my help and support of course) using the sample DLL on my site http://people.a2000.nl/rwvgesse/projects/Irdll32.zip

Regards
Ruud

Ruud

October 13th, 2002, 03:55 PM

Getting the hang of it... :smile:

I have recently modified the programmer software(http://people.a2000.nl/rwvgesse/projects/sw.zip) for the UIR/UIRT, it should now work under W2K and NT,, can anyone confirm that?

Ruud

Ruud

October 13th, 2002, 03:55 PM

Hey, one message didn't come through !!

Yes Mark, of course you may use the sources though I would considder using overlapped IO functions so there is some thinking to be done..

I don't understand the Q of you previous post..

Ruud

Ruud

October 13th, 2002, 03:55 PM

On 2002-03-08 01:37, ego093 wrote:
Hello all! I'm thinking about building a UIRT to work with my system, but have a quick question for those who have a fairly intimate knowledge of the unit...

I'm planning to use this with my Dish Networks equipment, which happens to run with a 57.6kHz carrier frequency. Is the UIRT capable of this? Is there some way to make it work if it doesn't already?

Well, the UIRT won't react too well to an IR signal with a carrier of 57.6KHz using the prescribed receiver but by changing 1 part, the receiver by a receiver with a center freq of 56KHz (withs are available) the receiving part will work great. The transmitter can easily be changed in the firmware of the PIC to support 57.6KHz..

So it can be done

Regards
Ruud

genixia

October 13th, 2002, 03:55 PM

I've been looking at the .asm code for the UIRT and also at the schematics.

It appears to me that it should be possible to assign an unused output to drive a MOSFET or relay in parallel with the ATX power switch in order to turn the PC on.

Obviously the schematic would need to be changed to allow the RS232 power to trickle charge a backup battery to keep the UIRT powered when the PC is off.

The way I read the code, we'd insert a trap just before SndData0 to compare the IR code with a known code, and if they match we branch to a routine that sets the new pin high for a predetermined time, before goto'ing main.

I see a few issues with doing this:
1) We'd have to find a known code that was not in wide usage already. This code would have to be hardcoded into the PIC, so it has to be something that can be programmed on a pronto, and preferably also a OneForAll remote.

2) The main initialisation code for the PIC checks the RS232 communications before it starts to listen to the IR. This means that the first time the UIRT is powered up the PC must already be on. It may be possible to rewrite the initialisation code to not check the RS232 until the UIRT wants to send data on it, but this could have ramifications.

3) Battery life. Has anyone thrown an ammeter on this thing to see what the power consumption is?

4) ATX power connection. I'm assuming that an ATX power switch is a normally open switch that when closed ties a sense line to ground, and hence the parallel MOSFET idea should work. Does anyone know more about this?

genixia

October 13th, 2002, 03:55 PM

Ingo,

Can you post the Eagle files somewhere and I'll take a look.

As regards the high power switching, it could be done with a Triac or a Silicon Controlled Rectifier, or easier, a relay.

However, I think that you'd be best advised to leave this board only dealing with CMOS level outputs, and let the end user worry about interfacing to higher voltages. There are devices commercially available that will switch higher voltages based upon a low voltage trigger, and it's just not worth the risk of litigation should someone-else use your design and get fried because of it!

For my use, and many other girder users, X10 is the way to deal with switching high voltages. It's COTS technology with a proven track record. Plus, girder supports X10 wonderfully via serial->x10 interfaces.

[ This Message was edited by: genixia on 2001-10-17 18:13 ]

genixia

October 13th, 2002, 03:55 PM

Jediperry,

The idea of being able to learn the Power On code is a good one. I had discounted it as I realised the code complexity for this function could be high, and also because I was unaware whether the PIC had run-tiem programmable flash onboard.

However, if it is possible to get a pin compatible version of the PIC with onboard flash then we should be able to do this more easily. Rather than learning the code direct from the IR, we should learn the code into girder, and then reprogram the flash through the serial port, as this should be more robust.

It may be possible to be able to avoid the need for flash completely - if the Power On code is stored at a known address in the .hex file, uirprog could be altered to modify the hex and reprogram the PIC with the desired Power On code on the fly. This would eliminate the need for part changes. Plus, code development could be done on existing boards as the unused pins are easily accessible to a logic probe.
New schematics and boards would only be needed when adding in the battery backup and mosfet stage.

[ This Message was edited by: genixia on 2001-10-17 18:20 ]

genixia

October 13th, 2002, 03:55 PM

jon_rhees,

Is there anywhere I can get hold of the modified .asm files?

genixia

October 13th, 2002, 03:55 PM

Great news about the storage area!

One observation that I do have is that each received code would have to be compared to each 'in the pic' code before transmitting to the RS232 port. If I read the .asm correctly, each code is 6 bytes long, each byte of which would have to be compared in turn.

For one code I don't see an issue, for 2 codes the delay probably wouldn't be noticeable, but for 5 codes (number of unused lines) we'd be talking about 30 byte comparisons and assosciated branch ops that would need to be executed, and this may cause a noticeable delay in processing IR commands to girder. Maybe some experimentation is needed in this respect?

genixia

October 13th, 2002, 03:55 PM

Hmm.

Well, I'd be happy with just the pulse option, as it'd achieve what I want it too - turn my PC on. After that, girder and X10 can do everything else.

But,
As you have offered these wonderful feature-rich options (and we'd be fools to reject the offer!), I'd suggest (if possible) a toggle option, ie change state regardless. The reason I suggest this is because if set a line high with one command, then another command would have to be used to set it low again. That takes out 2 of the 4 codes on one output line...The only problem with the toggle option is anti-repeat would need to be coded in.
Unless it is possible to program in more than the four codes without causing IR lag, in which case 8 codes covers 2 states for each of the four lines, in which case the toggle option's need is diminished.

As for the control of output lines from the PC, this could also be a nice option. Again, IR lag might start to be a concern. I'd reuse the same codes. So we'd end up with a number of programmable codes that were always trapped by the UIRT regardless of source interface, and used to switch PIC lines rather than passed through.

genixia

October 13th, 2002, 03:55 PM

Ingo,
Yeah, The codes coming from the PC could be different, and could also contain a special charactor in the first byte to minimise latency. Obviously this byte would need to carefully chosen to ensure that established codes didn't get masked out from the transmitter.
The reason I suggested using the same codes was to minimise storage requirements - this potentially allows for more than 4 codes to be stored. I don't know exactly how Jon is planning his storage usage.
Aside from the latency issue, I don't see the need for the codes to be different, yet I can see a benefit in them being the same - once the code has been programmed to respond to the IR, the exact same code can be used in the girder command to do exactly the same thing. This makes sense to me and will help users to set this up correctly.

Jon,
I agree with Jediperry. Go with the easier to understand and implement solution! After all, we are going to be able to girder-automate mulitple commands. :wink:

Just to throw a spanner in the works before we tie up all the I/O pins and eeprom space, does anyone see any benefit in defining one of the pins as an input rather than an output, and allowing that pin to trigger a programmed code to be sent to the PC and/or IR ???
I don't personally see the need, but I thought I'd throw the question out there before this all gets set in stone.

genixia

October 13th, 2002, 03:55 PM

Hmm. No, interesting idea. I had looked at WOL briefly a while back, but had forgotten about it.

Questions:
Does WOR work directly on serial ports? I noticed that motherboards have a WOR connector by the PCI slots, and always assumed that WOR needed an internal modem.
Does WOR/WOL wake a PC up from off, or only from standby? I think we need to cover all the bases - some people don't like using standby for various reasons.
Do you know how the WOL/WOR connectors on the PCI board actually work?
Are you sure that all ATX mbs support WOR?

It may be possible that you have just given us another useful option.
Or it may be that you have just solved the Power Switch connection dilemma - if the WOL/WOR connectors on the mb work the same wat as the power switch, then we potentially have 2 internal connection options without have to rewire the power switch.

genixia

October 13th, 2002, 03:55 PM

Ok. WOL motherboard header could definately be used.

It provides 5V standby power at 600mA at all times, GND, and the WOL signal input - a 50ms pulse GND->5V->GND wakes the PC.

ftp://download.intel.com/ial/wfm/wol_v17.pdf

Still looking for WOR details. (Hopefully the same)

The only downside about using WOR/WOL is that the same code couldn't turn the PC off. But do we really need that with girder installed??

genixia

October 13th, 2002, 03:55 PM

I've been looking at WOR more, and I don't think that WOR is really viable. The problems:

1) I can't find the motherboard WOR header specs. Most mb have a 2 pin header, and the one spec I could find suggested that this was 5V standby and the WOR signal, but no definition of what the WOR signal needs to be.

2) WOR was originally designed to operate from Standby more S1 only. Newer mbs may or may not support wake from S3, or wake from Soft-Off, but again, finding specs for this is hard.

3) Some motherboards support WOR using the RI line on the serial port, allowing WOR via an external modem. However, it is not clear whether this applies to the first com port or all com ports, and possibly differs between mbs.

4)It appears as though the X10 serial interface CM11A uses the RI line to try and wake the PC whenever it sees an X10 command on the power lines. This could be a problem when combined with (3).

When you combine all of this information, it appears as though we'd be entering a minefield with regards to different users getting different results - it'd be worth considering if it were the only option, but given that we have 2 other options that both look more robust I'd say lets forget WOR.

WOL on the other hand does look like a good possibility. The WOL specs have been driven by the enterprise industries as a means to wake up PCs to perform routine maintenance. There has been more industry support for WOL due to the fact that most office PCs are already on a LAN, and finding information on the header is also easier.
The only problem with WOL is the fact that some people may already be using it within their home networks. I'm looking at piggybacking possibilities. The only issue with this is ensuring that neither the NIC or the UIRT blow up. Protecting the UIRT is easy (we get to design it), protecting the NIC less so.

Piggybacking the Power switch as originally suggested is a walk in the park - it just needs a suitable cable, and there's no problem with having to protect the switch.

[ This Message was edited by: genixia on 2001-10-18 19:56 ]

genixia

October 13th, 2002, 03:55 PM

The ATX power switch appears to switch 5V standby (ie always on) to a request line.

If we used the power switch, it should be no problem - we get constant 5V like with the WOL header.

The only thing missing at this point is ground. However, I'm sure that there are plenty of ground pins unused near the power switch connector, and we probably don't even need to bother with this as the RS232 casing should also be ground. I'm not aware that any motherboards switch their grounds - for the life of me I couldn't understand why they should.

So,
I'm going to work on the premise that we need 2 wires into the UIRT - one that carries the 5V standby that is used to power the UIRT, and one that carries a switched Gnd->5V signal back.
I'm thinking about using a quad buffer chip rather than transistors/MOSFETs, and just making the other 3 lines easy for people to get at (DIL pin headers, line and ground). The buffer will protect the PIC from stupidity.

Thoughts anyone?

genixia

October 13th, 2002, 03:55 PM

On 2001-10-18 22:20, Robin wrote:
...
Perhaps we could build something that can have modules added ... I really don't want to wire to the power connector, it's the least documented aspect - my current config doesn't even have a switch, I just tap the wires together /phpBB/images/smiles/icon_smile.gif

Jon-Rhees hex developments sound like they are being adapted to suit all needs, it's just the power switching hardware that's being questioned ... the WOL & Power switch seem virtually identical (aside from the physical connection ... and I wouldn't separate ground, I think that's what needs dragging up to 5v), whereas the WOR should be very straight forward for those with a BIOS that supports headerless WOR (like both of mine).

Can't we develop an attachment that solves both (all three /phpBB/images/smiles/icon_wink.gif) cases ?

Hmm. I don't think you really meant to say that we wanted to drag ground up to 5V :wink:

Anyway, I think that it should be no problem to provide for one of the buffed outputs to be wired to a pad that you could connect the RI signal of your RS232 cable to, as well as to the connector block... Then people can try this if they wish. TMMV...

They'll still have to power the unit somehow though - without that 5Vsb coming from either the power switch connector or WOL connector, the UIRT isn't going to wake anything! :wink:

[ This Message was edited by: genixia on 2001-10-18 23:14 ]

genixia

October 13th, 2002, 03:55 PM

Ok. I must be missing something obvious.

Where is this circuit deriving it's ground from? As far as I can see in Ruud's original circuit, the circuit ground is floating, which makes it a bl**dy miracle that it works at all.

I noticed when trying to figure out the new power connections - Ruud got clever by using the RS232 ground as the circuits 5V, and then letting the circuit ground sit at -5V wrt the RS232. (although as pointed out above, it is actually floating..)

He did this so that he could get the required programming voltage out of the RS232...

This leaves me with a bit of a headache...

genixia

October 13th, 2002, 03:55 PM

Hey Jon,

Can you explain a bit more about your mod?
I'd really like to remove all of the RS232 power, and shift the circuit ground back to RS232 ground.

Do we need the 12V for programming these new codes in or only for the inital programming?
It isn't clear to me whether you are intending to program the eeprom from the UIRT plugin in girder or from the flash programming utility.

If the eeprom code programming can be done without the 12V, then this could make my design much easier.

What I am thinking is that the power into the UIRT is going to come in on a pin block, and that for the flash programming, rather than use a lead connected to 5V standby (that we're going to use for normal use), we'd connect a harness from the main PSU - the yellow wires are just the voltage we need :wink:

I know that this doesn't have the flash programming convenience that the current version has, but it will make the design of the always on feature much easier!

genixia

October 13th, 2002, 03:55 PM

On 2001-10-19 15:25, Robin wrote:
From my PC-Chips manual, it shows the power switch as 5v & Ground ... but it doesn't specify which one is the trigger.

Ok, the 5V should be 5V standby. The 'Ground' won't really be ground - it should be the power on trigger.

From what I remember of the basic electronics I did at Uni, switching can either be acheived by grounding 5v, or by pulling ground up to 5v ... so, to answer Genixia's comments, I really don't know which is necessary ... but I'll test it later.

What we need to do is pull the trigger (labelled 'ground') up to 5V for 50msecs. This is effectively what the power switch does by shorting the two pins.

If it's NOT the grounding 5v option, then this would make a good point to pick up standby power from.

That's why I suggested it :wink:

Lastly, if you're going to 'invade' the case anyway, you have complete access to Gnd, 5v constant, 5v & 12v rails anyway, just intercept the ATX power connector.

I don't really want to invade the ATX connector - too complicated for the average user. I can get Gnd, 5v and 12V from a molex if needed - although this is missing the constant 5v standby.

You could even fool the PSU by intercepting and falsifying the switch-on pin, getting round WOL, WOR & Switch problems !

I don't know for sure that this will work - it may turn the PSU on but not boot the motherboard cleanly. I'd like to tell the motherboard to boot as it'd normally do, and let it deal with turning the PSU on. That way we maximise the probability that it works.

Anyway,
I have bigger problems to deal with at the moment. The original circuit has the PIC's ground sitting at -5V, and it's +supply at Gnd. I can't just connect the 5V standby and ground instead, as it will probably break the programming, and more to the point will probably break the RS232 communications. Ruud used a very elegant kludge when designing this thing. One the one hand I am full of admiration, but on the other hand I'm really pissed. What originally looked like an easy mod doesn't any longer. We will find a way, but it's going to take a bit more thought...

BTW, looking briefly at Ruud's circuit, there is a problem with the 150ohm resistor connected between PIC pin12 and TxD. It is too low in value. Ruud states that this resistor isn't really necessary as the RS232 is current limited anyway, but to include it as good circuit design.

Assuming that the RS232 is swinging between 12V and -12V (which is by no means certain, but definately possible), when TxD is at 12V, the current being sunk by the PIC is 80MA, and when TxD is at -12V, the PIC is sourcing 47mA. Both of these currents are too high according to the PIC specs, which means tht if someone is unluck enough to have a non-limited RS232 port, they might blow up the PIC. A 330 ohm resistor will change these currents to +36mA/-21mA, which is more in line with the specs.

Does anyone want to check that this works?

genixia

October 13th, 2002, 03:55 PM

Thanks Jon!

The transceiver accepting 0V/5V signalling was the part that was causing the headaches with re-grounding the circuit. Now I know this, it should be fairly simple.

genixia

October 13th, 2002, 03:55 PM

I'm going to be offline over the weekend, so if anyone has any questions/suggestions, I'll catch up with them on Monday.

genixia

October 13th, 2002, 03:55 PM

Ron,

I don't know at this point how much value we would gain from having a separate forum for the UIRT.
This thread has obviously evolved a lot from it's original purpose but I think it has evolved in a logical manner. I anticipated posting a new thread once the hardware design changes are made, but I wasn't anticipating starting enough threads to warrant a separate forum :wink:
Long term, I would hope that we can finish a HW/SW design that will work for the vast majority of people, and that the development work on this will slow down considerably when we have. At that point, I forsee a few months of people getting to grips with building and using the UIRT, and we will see teething issues, but hopefully not a huge number.
I would suggest that if you were to create another forum for the UIRT, then you would actually create a 'Girder Electronics' area that would also encompass topics such as LCD/VFD display development and other projects of a similar nature that may arise in the future.

I actually think that the current forum model of general and development needs overhauling anyway - I think that we would gain from having more modular-specific forums, and keeping development threads integrated within them.
The only separate development forum that I can really see a need for is 'Core Development', that discusses girder's core architecture and module integration issues.

I think that it is obvious that the user base of girder is growing fast, and that the forum structure needs to be able to keep up with this - Perhaps you should start a new thread in each forum and solicit ideas from others in this regard? (I nearly did that instead of posting this reply, but I didn't feel it was really my place to do so :wink: )

genixia.

[ This Message was edited by: genixia on 2001-10-22 18:33 ]

genixia

October 13th, 2002, 03:55 PM

Good work Jon!

I need some clarification on a couple of items to ensure that my design changes will work:

RTS line:
From studying Ruud's schematic, it is my understanding that during normal use this line is *always* pulled low so that MCLR sits around the PICs ground level, and that the only reason that this line is there is too provide the circuit with it's fake ground.
(It should actually be sitting at -5.7V real due to the diode drops of the 5V1 zener in series with the 13V zener, with approximately 6V dropped across the 10k resistor R4.)

During programming, the RTS line is pulled to +12V to provide Vpp for the PIC, and the GND pin stays at -5.1V due to the 100uF capacitor C1.

RA2,3,4:
These pins are tied to MCLR during normal use, and left floating during programming. I have no clue as to why they need to be tied during normal use - it appears as though they are unassigned in the PIC code, and the only reason that I can think of is to ensure that the GND of the PIC doesn't rise when current is being drawn, although I can't see how/why.

Can you confirm from the programmer code, the girder plug-in and the .asm, that I'm understanding this correctly?

If I'm understanding this all correctly, my current intentions are to use a pulldown resistor on MCLR, and use RTS to switch a FET from a temporarily connected +12V line for programming.
In fact, do I need to switch this line at all? Can I avoid the FET? If the programmer just switches this line high and leaves it there indefinately, then I could probably just connect the 12V line straight in? Without knowing how the programmer and girder plugin work, it's hard for me to tell.
(I'm also going to add a jumper connection so that people can try driving MCLR directly from RTS for programming rather than a separate line, although it's doubtful whether this will work - the PIC specs state 12V min, 14V max for Vpp, and we can't know for sure that the average motherboard will hit +12V on an RS232 line)

On the output stage, I'm intending to rework the LEDs so that they are driven by a transistor from one of the 2 pins (RB4/RB5), and provide a second drive stage from the other that will be terminated with a microphone jack. The only consideration is that the ATX spec declares 600mA on the 5V standby line, and each stage will be pulling 100mA. I don't see this as a problem, but until testing begins...

I am going to somehow buffer RB4 as an input pin. I'll provide some voltage protection so that 12V switching can be used into it as well as 5V.
I am going to use RA0 as the 'wake up' pin. This is completely arbitrary, but I'm going to provide a route on the PCB for this signal to be wired to the RI line of the serial port so that people can try using this as discussed earlier.
I'm still debating (in my head) the output stages for the other pins, ie whether just to buffer the 5V logic, or to provide an open collector output so people could easily drive relays..

Opinions anyone?

genixia

October 13th, 2002, 03:55 PM

Thanks Jon,

I had realised after re-reading the PIC specs that my assumption was wrong wrt to the line staying low...

Ok...how about this: The 12V is not connected during normal use. The diode protects the 5V supply during programming - the PIC specs lists Vih for MCLR at 0.85Vdd (= 4.25 at Vdd=5V). Hence the diode may need to be germanium (0.2V drop vs 0.6 for silicon).

Thoughts?

5V --------- ----12V
| |
|--|>|------|--|
|
|
|--
||
||<-|
RTS-------|| |
|--|
|
|---------MCLR
|
Z 1k Ohm.
Z
Z
|
|
--------- GND.

[ This Message was edited by: genixia on 2001-10-23 00:50 ]

genixia

October 13th, 2002, 03:55 PM

Hmm...Good question. I guess the diode solution is a bit more elegant - it is impossible to set a non-existant jumper incorrectly, if the 12V wire is attached then you're all set to program the PIC, and if not then you wont be able to yet the device will still work.

And, it's one less solder joint to make! :wink:

genixia

October 13th, 2002, 03:55 PM

Jon,

Have you looked at the 16F628 at all?

http://www.rentron.com/PIC16F628.htm

I appears to be pin compatible with the 16F84A, but is lower cost ($3.58 from Newark) and appears to have some features that could be useful:
Internal 4MHz Oscillator - We may possibly be able to remove the xtal completely.
Internal analog comparator module.
Internal PWM module.
Hardware USART - Interrupt driven RS232 ??
2k program space (vs 1k on the 16F84)
128bytes EEPROM. (vs 64 ....)
5V programming...
15 possible i/o lines (some of the above options would use some of them..)

In the short term, I think that it should be possible to use this device as a drop in replacement for the 16F84 with current designs, with minor .asm file changes needed to configure the pins correctly. Another .asm file change should allow us to test using the internal oscillator.

In the long term, I think that this device has a great potential for the UIRT. To make use of some of the new features though would require design changes to the circuitry:
USART uses RB1/RB2 - currently flagged as output pins in the forthcoming design.
Comparators use RA0-RA4.
5V programming uses RB4 - currently used as IR transmit.

So Jon, can you take a look at this? I'm guessing that this forthcoming design will keep using the 16F84, but if you decide that you want to use this instead, or to reassign some of the pins with a view to using this in the near future, then let me know.

genixia

October 13th, 2002, 03:55 PM

Quick question:

Does anyone have the specs for Smarthomes IR emitters? I need to know the polarity of the miniplug. I'm assuming that the tip is the anode, and the shroud is the cathode, but I can't find this information anywhere...

If anyone knows what the VI characteristics are then this would be useful too so I can suggest R values, although this isn't nearly as important.

genixia

October 13th, 2002, 03:55 PM

Ok. Second things first:

I don't want to get involve in RF design at all. There's too many complicated factors involved:
1)You haven't specified what you are trying to control using RF. The frequency and protocol used tends to be device specific.
2)The FCC has strict controls on what frequency bands are used for, and how much power can be transmitted etc. If I were to design a circuit that fell foul of those controls, I could be in trouble. Further, if you were to build that circuit, potentially you would be the one getting caught and fined. I have no need to complicate my life :wink:
3)I don't know jack about RF design.

I'm guessing that what you want to do is to use a pyramid (or similar) rf remote extender. This works by modulating ir codes onto a radio signal and transmitting it to a receiver that demodulates it and transmits it as IR again... You should be able to use this in conjunction with the circuit that I am designing. The circuit is going to be capable of driving a second IR emitter that could be pointed at the pyramid.

genixia

October 13th, 2002, 03:55 PM

On 2001-10-25 02:45, Danijel_Pticar wrote:
Hi.

I have now converted 4mhz code to 10mhz+some small fixes in code. I menaged somehow to code girder plugin, its beta*2 writen using borland vlc so its little big.. Also I have fixed UIRT programmer so its should programm all PICs now on all OSes.

It would be great to someone test Transsmit. I have tested it on TV and video only.
Also if someone will test on RC5 remotes it must grab both codes, and transmith both codes.

files are located at http://student.math.hr/~dpticar/uirt.htm

bye ...

Clarification:

Please note that Danijels firmware and software are his own, and whilst they appear to share a common code base with the software and firmware discussed in this thread, they are not the same, and perhaps this post should have been in it's own thread to avoid confusion. If you choose to use Danijel's work, please post any feedback in a new thread!

Jon_Rhees is developing the UIRT firmware that has previously been discussed in this thread. He is currently modifying it to increase functionality as we have discussed above, and I believe it should be backwards compatible with the original UIRT HW design.

I am currently working on a new hardware design that will be optimised to use Jon's changes. Again, this should be backwards compatible with old firmware and software.

Note that too make use of the advanced features that Jon and I are adding will require both the new firmware and new hardware.

genixia

October 13th, 2002, 03:55 PM

Ok, the design is nearly done...I need to clean up a few issues, and then I'll post the schematic for review along with design notes. I'm trying to make this design to be extremely flexible with it's input and output connections, and this is taking some time to get right.
If anyone knows of a manufacturer and model number of the Wake On Lan header found on motherboards, I'd find it really useful.

Jon,
Since the new HW design has changed the way in which MCLR gets it's signal, there is no longer a need to clamp MCL using the RA2,3,4 pins - during normal use it will only ever see 0-5V, and during programming 0-12V. (BTW, I dropped the proposed diode - I can deal with a jumper!)
So, what shall I do with these pins? IIRC, in the original design, RA2+3 were configured as inputs, and RA4 as an ouput for clamping purposes.
At the moment in the circuit, I have these 3 pins tied together and floating. I think that I could route them similar to the other pins that we have added - allowing for a firmware change to allow their use as well later on. However, before I do this, I need to ensure that you don't need me to do anything specific with them in order to retain firmware compatibility.

The other thing I need to confirm is which of the RS232 pins that were orginally used in Ruud's circuit are still needed. Obviously RTS,TxD,RxD and GND are - but which of the other 2? I'm guessing that CTS is used during programming, and that DTR was only used during IR transmission to boost power, and should no longer be needed???

Oh, one last thing - do you have any estimate of the average duty cycle of the IR pulses?? If I were to use the same R values as Ruud's circuit, we'd be pulsing the LEDs at 1A. I don't believe that Ruud's circuit managed to obtain this much current from the RS232 line, so I'm trying to find a suitable current figure to use.
(The ATX specs for P4 compliance dictate 720mA being available on the 5Vsb line. According to a couple of specs I researched, the Antec250W will provide 1.7A, and an Enermax 350W will provide 2.2A .Going with the Antec figure, that should give us 1A of current headroom above what the PC would otherwise need)

genixia

October 13th, 2002, 03:55 PM

On 2001-10-27 20:24, jon_rhees wrote:
Genixia,

In your circuit, please make sure you have the ability to leave MCLR 'high' all the time (even when the PC is OFF). Keep in mind that the PC Serial port will sink all of its outputs to Ground when the PC is off, and if MCLR is held LOW, the PIC will not be able to continue to receive IR codes and toggle port pins, etc.

The caveat with simply tying MCLR high is that the unit will no longer act like a true UIR. Also, you'll have to make sure the 16F84 has built-in power-up reset capability.

You could make a fancy circuit which controls MCLR from RTS but ONLY when the PC Serial Port is powered...

As far as the RA2,RA3,and RA4 lines, they are not used in code. The way the new Port pin control code is written, these can easily be added as more output pins which girder can control -OR- input pins which can generate girder events.

Any pins you designate as inputs, you'll want to have a pull-up on-board to keep from floating.

-Jon

If I understand you correctly it should be easy:

Currently the design uses an enhancement mode n-channel MOSFET to pull MCLR up when RTS goes +ve, with a resistor to pull it back down to GND when RTS < ~1V. You've spotted the flaw with this design.
So, instead, I'll use a p-channel enhancement MOSFET to pull MCLR down to ground when RTS goes -ve, and a pullup resistor to [5v|12Vpp] when RTS > ~-1V.

I think that this should work - assuming that RTS does indeed swing negative, and doesn't just swing to ground.

genixia

October 13th, 2002, 03:55 PM

On 2001-10-28 18:38, jediperry wrote:
OK, just bodged together a test circuit, using U24MHZ10.HEX 1.1a.
The 4 IO pins work fine although I havn't got round to connecting them to anything yet. The wol header is the next step but I need to buy a buffer chip tomorrow.
AS for TX, no success yet. I am only running it from the dtr line at the moment so its probably just not getting enough power.

My only suggestion at the moment, although I am not sure how it could be best implemented, is an option for girder to block the control of an IO pin once booted. i.e. it would be nice to be able to use the power button on my remote for other things without turning the pc off again. /phpBB/images/smiles/icon_biggrin.gif (Although, now I think about it, this probably won't be an issue if wol is used (?))

Mike, I just hacked a web page together with my current schematic so you can take a look at how I'm intending to do things. It includes a buffer chip (ULD2003A - 7x open collector logic drive darlington, fairly easily available and low cost).
If you don't need in-circuit PIC programming, the FET can be removed, and MCLR driven from RTS via a resistor with zener clamps...

Let us know what you think..

http://h0000e108b21e.ne.mediaone.net/genixia/UIRT/index.php3

[ This Message was edited by: genixia on 2001-10-28 23:45 ]

genixia

October 13th, 2002, 03:55 PM

Hmmm. You're right about the FET. It might be possible to remove the FET, and feed the junction of MCLR and the 1k resistor with the RTS signal via a well chosen capacitor - effectively spiking MCLR low on a negative RTS transistion. The danger here is that a postive RTS transition puts a high voltage on MCLR and the PIC enters programming mode. This could be avoided with a zener, but once you start doing this you have to ask why you didn't just use the FET in the first place! "Use the gate,drain and source Luke..."

RB0 is the input that will be able to trigger a girder code. The RC network is there for debouncing and current limiting. The PIC has clamping diodes that will clamp at Vdd+0.5, GND-0.5 (ie 5.5V and -0.5V in our case), R5 should be chosen to limit the current to <25mA. 1k should give 6.5mA on a 12V trigger. C3 can be added to debounce the line should a manual switch to 5V be used instead. ( I don't know how well the PIC code would deal with an unbounced signal - C3 might not be needed at all. )

Apparantly CTS is used during programming. PIC programming is done via RB6 and RB7. One is the clock, and one is the data, but without the spec in front of me I can't tell you which is which. In normal use, RB7 transmits to the PC via Rxd. During programming, the PC transmits to RB7 via CTS. Or so I am led to believe :wink:

[ This Message was edited by: genixia on 2001-10-29 06:24 ]

genixia

October 13th, 2002, 03:55 PM

Thanks Daniejl,

I've never designed RS232 interfaces before, so this is a learning curve. I will correct that.

genixia

October 13th, 2002, 03:55 PM

Yes, I'm still working on this. It's had to take a back seat for the past couple of weeks due to family events and other events such as getting made redundant, but I should be be finalising the design soon.

genixia

October 13th, 2002, 03:55 PM

I'm back. Sorry about the long delay. Life got hectic and other things (eg Christmas) got a higher billing.

Things I need to do -
Review this thread and verify the schematic again.
Decide on which technologies to use in the pcb.

At one point I was looking into providing 1/8 phono jacks for the outputs. However, I could not find any pcb-mount jacks that were easily available, compact and that had their pinout in eagle's libraries. This was causing me to procrastinate far too much, so last week I took the executive decision that it will be much easier for all concerned to use a panel-mount jack and leads for the outputs desired. This means that I only need to provide the appropiate pads.
The same goes for the WOL/WOR header - Despite my best efforts, I have been unable to identify a part number for this header which in turn means that I'm unable to produce a pinout for it. So I'll just provide pads for wires instead. It means that I'll have to be clearer with documentation and people will have to be more careful when building it, but so be it.

This circuit is very difficult to route - virtually impossible for a single-sided board. As I don't own any pcb manufacturing chemicals or gear, I was going to get doublesided boards made at either http://www.olimex.com/pcb.html or http://www.apcircuits.com (but I will publish layouts for the more adventurous anyway.) I will be sending freebies to the deserved, and selling the rest to cover costs.

My questions to you guys is - How comfortable are you with surface mount soldering? It is possible to solder SMT chips with a heat gun and some practice (old computer components are useful for this), and smaller parts with a regular soldering iron. Or I could go hybrid with DIP chips and SMT passive components. Or completely through hole.
(For those who are going to produce their own boards I can publish any/all of these variants.)
The advantage of SMT is mainly size reduction. My preliminary layouts suggest that 2x3 inches is about as small as the PTH board could go (especially if I create a single sided board - jumpers will be needed).
A nearly pure SMT board might get into 2x2 or thereabouts.

Jon,
Currently RA2/3/4 are still connected as they were in Ruud's original schematic. I have one unused buffer, so one of these could provide an additional toggled output/LED stage, and the other 2 converted to debounced inputs. Do you have any preferences?

So currently, the design contains:
RB4 & RB5 :IR LED outputs, RB4 drives onboard LEDS, RB5 is available to drive an external emitter.
RA0 : Output - will drive RI on serial port (if connected), and also WOL header in addition to external pads. Intended to wake the PC up.
RA1, RB1 & RB2 - external outputs.
RB0 - debounced input.

RA2, RA3 & RA4 - undecided.

Let me know as soon as possible. I'd like to get the schematic cast in stone this week, and the layouts finalised next week, and hopefully get an order in to a boardhouse then. (And spend the interim time documenting this thing!)

genixia

October 13th, 2002, 03:55 PM

aderusha,

I think you missed my meaning somewhere! I willing to publish board layouts on the web for the home pcb manufacturer in whatever technologies they want (within reason!), so a single sided pth is a probability (although it's a bitch to route!).
My question was really regarding those boards that I'm going to pay to get made, so aimed at those who are going to a freebie (and they should know who they are :wink: ) and those who might want to buy one. Obviously it's pointless me sending or selling people pcbs if they are unable to solder them, and it in my best interest to be able to recover as much as the manufacturing costs as possible!

genixia

October 13th, 2002, 03:55 PM

Re: CNR.

While it's an interesting idea, it's not really feasible for this project for a number of reasons.

I just perused the CNR 1.2 specifications on Intel's development website (http://developer.intel.com/technology/cnr/).
I'll list the reasons that I see below:

1. A single CNR riser is supposed to support many integrated functions - LAN, USB, AC97 sound etc. Our device would have to support these too to be compatible. Of course we could choose not to support them, but then those people actually using CNR would not be able to use the UIRT.

2. CNR does not support 'Plain Jane' serial, only USB. RS232 has some benefits over USB. It's a very well established, common standard that is found everywhere. That means it is relatively easy for Jon and the other coders to work with. APIs and example code for serial implementations are far more common than USB. Serial ports also don't require additional OS drivers to be written - they already exist.

3. CNR is supposed to be plug&play. That means drivers would need to be written.

4. The mechanical aspect of the pcb fitting into the CNR slot correctly is not something I want to have to deal with in the pcb software.

5. The pcb that I am designing is intended to make the UIRT more flexible than the original - both in terms of functionality (additional digital inputs and outputs that can be used to trigger girder or drive external relays, waking up the PC etc), and also in providing people with options - you can decide whether to use the WOL/WOR header or whether to 'piggyback' the powerswitch to power the device and wake the PC. If you don't care about the wake-up element, you'll be able to wire in a molex connector instead. (I'm considering making it possible to use both at the same time, so WOL power is used when the PC is off, but standard 5V is used when the PC is on - we need to get 12V to the board anyway for programming, and this option might be useful for some people.) The point is that everyone has slightly different needs, and this pcb will hopefully address a lot of them.

6. I don't know Jack about CNRs!

In the future, I envision that someone will create a UIRT that is PCI based, with an inbuilt X10 controller on the same card. I imagine that the era of home automation will be snapping at Convergence's heels...

jcase

October 13th, 2002, 03:55 PM

What PIC chip is the correct chip to use in building the UIRT
PIC16F84-10I/P
PIC16F84-10I/SO

Also Radio Shack is carrying this one:
16F84A-04/P Flash Microcontroller
$5.99 Reg. Price
Brand: Microchip
Cat.#: 900-8650
Model: PIC16F84A-04/P

The documentation on the website states that the UIRT uses the 10MHz vs the UIR uses the 4MHz version

Please let me know what is currently being used in building this wonderful device.

thanks

jcase

October 13th, 2002, 03:55 PM

What crystal are you using?
Newark.com p/n would be fine since I plan to order my parts from them as well.

thanks

jcase

October 13th, 2002, 03:55 PM

I have etched the board and started assembling the board. I don't understand how the ir receiver should be attached. By comparing the schemating and the etched board, the pin configurations seem to be wrong. The picture of the UIRT has the receiver facing in a stange direction. Can anyone clarify this?

thanks

jcase

October 13th, 2002, 03:55 PM

I determined that the ir receiver needs to be mounted upside down I think. When I assembled the UIRT and tried it it will not program.

Has anybody built and got this to work. If so then please help me clarify what is wrong.

thanks

jcase

October 13th, 2002, 03:55 PM

Well I have completed 2 of these, one using the etched board the other on a bread board. I still have the parts for a third. But I'm getting a little frustrated.

I'm having a problem programming the PIC on both boards it gets to like 99% and dies. I sent an email message to the creator, his response was that his internet was down and would be looking at it.

Has anybody else had a problem programming it. I have tried it on 3 different computers:
Toshiba portable running W2K
IBM running W98
GigaByte Motherboard AMD running ME

I wonder if the problem is with the software since it was re-written recently?

Any help would be greatly appreciated.

I have posted a drawing of the parts layout here
http://www.caseserve.com/ht/uirt.htm

thanks

jcase

October 13th, 2002, 03:55 PM

I read somewhere that he changed the program to work with Windows2000, I wonder if in doing so something changed to make the program inoperable.

Do you know where we/I can get a copy of UIRPROG.EXE prior to:
Created: Sunday, August 26, 2001, 2:08:36 PM
Version: 1.0.0.1

Did you follow the link from my previous post. If you compare the schematic to the layout of the components to the circuit board I think you will see what I mean, no where do the pins line up in 1,2,3 order other then the way I described earlier by inverting the receiver to the buttom of the board and sharing the hole in the pc board for the transmitter.

I also don't believe that the placement of the IR Receiver has an effect on the programming of the PIC. Because I have built two of these now, on one of them I have not installed the ir receiver yet. But it programs exactly as the completed one.

jcase

October 13th, 2002, 03:55 PM

AWESOME :smile: :smile: :smile:

That was the problem, the programmer is corrupt, also his pin out is wrong. Pins 2 & 3 are reversed

I now have 2 working UIRT's and parts to build a 3rd one.

Have not tested sending yet.

jcase

October 13th, 2002, 03:55 PM

It seems that my remote is sending multiple ir codes for the same key press, like every third press of the same button produces a different code, but it is the same 2 codes
press 1 = 05f06a81dc43
press 2 = same
press 3 = same
press 4 = 434d0555dc43
press 5 = same as press 1
and so on it goes

Any idea? Girder is new to me since I just built the UIRT :smile:

jcase

October 13th, 2002, 03:55 PM

Yes, I tried it between 1ft to 8ft with the same outcome. I could possibly that interference as causing it if it was not the same 2 codes.

The remote that I was using was the Marantz RC200MKII

jcase

October 13th, 2002, 03:55 PM

Does anybody have a copy of virtualremote. I'm unable to access the website.

thanks

jcase

October 13th, 2002, 03:55 PM

Very nice site.

Now if we can just get the coding done to allow send and receive directly from Girder without the Virtual work around we'll be set :smile:

jcase

October 13th, 2002, 03:55 PM

Just wanted to check to see the the "T" is working?

thanks

October 13th, 2002, 03:55 PM

Hello,
If someone have problems with programming UIRT it can check http://student.math.hr/~dpticar/uirt.htm , I have puted there uirt programmer, Its for 4mhz versions buz should work with 10mhz (I think).

bye

October 13th, 2002, 03:55 PM

I looked at the test program, but it wouldn't test in UIRT mode: it says that the UIRT didn't respond with "OG", but the specs on Ruud's site say that the UIRT should repond with "RO" in native mode! What version of "UIRT" (with a 4MHz clock?) was this written for?

All software is writen for Ruud UIRT but with 4mhz clock. His protocol is different than my. Only IR-OK (UIR) is same. His software runs at 56k baud at grab/transmit mode, and my is always runing at 9600 bps.

I have described protocol in OLD SOFTWARE files.

You have to use 4mhz crystal to use software...

cya

Dionysus

October 13th, 2002, 03:55 PM

Hey guys, I plan to build one of these sometime in the next few days but I'm an uber-novice at this sort of thing (only one ECE class in college) so I want you guys (oe1k, jcase,..) to stay handy in case I have any questions or needs. Thanks!

Dennis

Added on edit:
oe1k, is the model you produced working successfully?

[ This Message was edited by: Dionysus on 2001-09-17 10:11 ]

Robin

October 13th, 2002, 03:55 PM

Erm ... I've built my own HTPC, but I wanted something a little different ... it plays DVD & MP3 without effort, but it's also a file-server, using the Wake-On-LAN functionality to allow my other PC's to wake it.

I had intended to use the Wake-On-Modem through the UIR to switch it on, although I haven't rewritten any PIC code yet.

Reading through this dialog, you all seem very keen on 'hotwiring' the ATX Power-On connectors, which seems a little strange as all ATX boards seem to support Wake-On-Ring anyway.

Surely (as we're using a serial port here) it would make more sense to:
1 - Learn the 'Power' IR data in Girder
2 - Upload the 'Power' IR data to the PIC
3 - Alter the PIC's comparison code to replace all instances of the given IR data with RING, which would wake the PC.
4 - Alter the PIC's coding so that the usual start-up code simply restarts the PIC ('IR' & 'OK' on the standard UIR).

Or have I missed something obvious ?

Robin

October 13th, 2002, 03:55 PM

Thanks for the heads-up on the WOL ...

My desktop PC currently uses WOL & WOR perfectly (Gigabyte motherboard), it's currently acting as an e-mail server so WOL is used by my wife's PC and the WOR means I can phone my PC from my mobile as I drive down the street and know that it's there waiting for me when I get there.

Both work well from soft-off (and standby), but not from 'cold'.

My new HTPC is based on a PC-Chips (shudder) motherboard (810LMR) which hasn't been that bad ... I added TV Out (G400) and used the on-board stuff for the rest ... unfortunately there's no WOL header (and the onboard NIC is being a pain) so I'm basically having to do what you suggested with the Power button :smile:

I'm still not sure exactly how WOR works, just that my external modem only seems to generate 'RING' when the phone rings.

Still, if there is an additional pin that needs switching it should be easy to incorporate once the enhancements are added to the UIRT PIC.

Just wondering if these codes really need to be flashed into the PIC and not just downloaded to scratchpad memory.

Also ... PIC's are voltage flexible, you _could_ operate it with 3x1.5v nicads and trickle charge direct from the PC.

Hope this is useful to someone ... if not I'll go back to lurking !

Robin

October 13th, 2002, 03:55 PM

Jediperry - I understand the difference between scratchpad and non-volatile (flash) memory, but my question still stands ... why use flash memory when the purpose of this device demands that it has constant power ?

Perhaps we could build something that can have modules added ... I really don't want to wire to the power connector, it's the least documented aspect - my current config doesn't even have a switch, I just tap the wires together :smile:

Jon-Rhees hex developments sound like they are being adapted to suit all needs, it's just the power switching hardware that's being questioned ... the WOL & Power switch seem virtually identical (aside from the physical connection ... and I wouldn't separate ground, I think that's what needs dragging up to 5v), whereas the WOR should be very straight forward for those with a BIOS that supports headerless WOR (like both of mine).

Can't we develop an attachment that solves both (all three :wink:) cases ?

Robin

October 13th, 2002, 03:55 PM

From my PC-Chips manual, it shows the power switch as 5v & Ground ... but it doesn't specify which one is the trigger.

From what I remember of the basic electronics I did at Uni, switching can either be acheived by grounding 5v, or by pulling ground up to 5v ... so, to answer Genixia's comments, I really don't know which is necessary ... but I'll test it later.

If it's NOT the grounding 5v option, then this would make a good point to pick up standby power from.

Lastly, if you're going to 'invade' the case anyway, you have complete access to Gnd, 5v constant, 5v & 12v rails anyway, just intercept the ATX power connector.

You could even fool the PSU by intercepting and falsifying the switch-on pin, getting round WOL, WOR & Switch problems !

Robin

October 13th, 2002, 03:55 PM

Well it's been a while since I last posted and if I wasn't confused before, I certainly am now. Apologies if I've got any of the following wrong.

There seems to be a choice of several schematics:
- Some work but only with the right firmware
- Some didn't work, but do with firmware 1.6
- Some might work, but haven't been tested (Genixia's designs)
- Two choices of PIC available (4 or 10MHz)
- In-Circuit / External programmable designs
- Listening / Deaf designs
- External power / RS232 power

All of which sounds like it needs to be rationalised a little.

I was hoping to build a circuit that used a 4MHz PIC, can listen for one IR code (& actuate), is programmed externally (JDM) and stable (5v) power is drawn from either WOL / WOR headers.

Would it not be possible to make this design more modular ? I understand different people have different needs for this project ... personally I just wanted a basic, (very) cheap replacement for my UIR !

If we had multiple designs, starting with the very basic core and swapping out sections to provide alternate functionality, would this clear the confusion ?

I'd be prepared to help rationalise and collate information if someone would help me understand what does what !

Robin

October 13th, 2002, 03:55 PM

Thanks Jon ... that schematic looks perfect.

Robin

October 13th, 2002, 03:55 PM

I've been happy with my UIR for ages now, but seeing the developments for UIRT thought I'd move on ... I don't have any real need for the transmit (yet), but I'm sure I'll find a good use when I have it.

The main reason for upgrading was the new Power On options ... thanks again Jon for that really easy to follow schematic.

As I'm using this device in a totally separate location to the PC (noise reduction by distance !) I wanted to put a push button on/off switch and a power status LED on the box.

The switch should be easy enough, as it looks like it just needs to sit parallel to the transistor.

The Power LED, well ... that's my question ... does the UIRT plugin still set RTS and DTR high so that 5v can be used from them ? I could then either invert that signal with a transistor and have an LED that's on when the PC isn't (like my TV) or use it straight to show that the PC is on.

Thanks again for a fantastic project !

Robin

October 13th, 2002, 03:55 PM

Stupid question coming up ... In Jon's schematic (PCPoweredNoICSP.GIF) the oscillator shown is a resonator, isn't it ?

I've built that circuit, programmed the PIC successfully, but still can't get it to work ... the only thing I wasn't sure of was the crystal (which would normally need two 15pf capacitors).

This circuit needs the two 15pf capacitors when you use a 4MHz crystal, doesn't it ?!

Robin

October 13th, 2002, 03:55 PM

Well ... I put the two 15pF capacitors in and I still can't make it work. I think the wiring is ok, although it was getting a little messy toward the end.

One thing bothers me slightly ... if I remember correctly RS232 is based on 12v, and this circuit only has 5v driving it ... so how is this PIC able to communicate (RXD) ?

Robin

October 13th, 2002, 03:55 PM

Well, I don't know what I was doing wrong, but I got fed up with it not working, so decided to bread-board a new one.

I left out most parts, the circuit ended up being PIC, Xtal, IR detector, 10 Ohm resistor, 1 x IR LED, 1x Green LED (so I can easily see what's happening).

Wired it all up and it behaved perfectly ... checked the wiring on my original attempt and tried again, still not working !

Think I'll probably put the cut down version in as the working model ... most of those resistors and capacitors are for ripple protection and input impedance correction, so I'll risk a few glitches (can always add protection later).

Thanks for your help Jon .. oh, and the 15pF's weren't needed !

Robin

October 13th, 2002, 03:55 PM

GMarkham ... I think this topic has been round before, but to re-cap ... USB might be nice but:
1 - It requires a USB device driver, which is harder to do than "simple" RS232 comms.
2 - I _think_ the 5v is only available whilst the PC is on (Not 5v standby).
3 - It's difficult to obtain USB connectors as a hobbyist.
4 - Most PC's have a serial port that isn't used any more (with most devices now USB!)

In short there doesn't seem to be a particularly good argument for changing over ... especially as this device is backward compatible with the original UIR (as a serial device) and can be used with existing software, albeit without the newer features.

Jon ... Thanks for all your patience and help with this project, I've now built my third UIRT (dropping all resistors & capacitors bar the 10k on TXD you recommended) and it's working very well.

Only one minor issue ... When I'm trying to learn codes for re-transmitting I often get read errors. Whilst I understand that this is probably my fault (Comms rate too high, poor wiring(!), missing components), the UIRT stays stuck in learning mode, requiring a complete power down in order to reset it.

Would it be possible to have either a learning time-out on the PIC or a soft-reset from Girder ?

Robin

October 13th, 2002, 03:55 PM

Jon,

Thanks for the tips ... however ... When my UIRT is trying to learn, it rarely gets beyond the third match in it's learning cycle and repeated attempts leave it stuck. I get some sort of read error from the Girder plugin and the device sits there still listening.

If I press a button on my remote I do get a lot of events flashing up on Girder, although when I stop pressing buttons the events cease ... Everything seems happy, with no data coming through, but the UIRT is still in "listen to all data" mode.

As my UIRT is powered directly from a 5vsb wire I have to unplug my PSU in order to reset the UIRT. I haven't had much of a chance to play with it yet, so I'll see if I can learn some more.

What would cause the plugin to give an error whilst trying to learn ?

Robin

October 13th, 2002, 03:55 PM

Jon - Why is it that whenever you want something to fail it never does ? The UIRT has been behaving itself all evening, although I'm still not able to learn certain codes ... My AIWA amp remote codes are easily received (regularly), but never learned, whilst my JVC VCR codes are easily learned.

I had thought that the learning phase was looking for 4 repeats, as my progress bar appears to jump in 4 chunks ... I now realise this was just a fluke. Girder never hung, just the UIRT wouldn't come out of learning mode (streams of data when a button was pressed, but nothing when 'quiet').

Any hints on why I can't learn certain codes ? Is there any info I can provide that might make the problem clearer ? What can I do with the IR Debug data ?

Eelector - Being in the UK, it's not easy getting parts ... so I swapped the recommended transistor for another cheaper part ... I used a BC337, but any reasonably quick NPN will do. DON'T forget the 1k resistor though !

Robin

October 13th, 2002, 03:55 PM

Eelector,

The description you gave is enough for Girder, however, you must make sure to link in all points that require 5v and Ground ...

5v should be present on pins 4 and 14.
Ground should be present on pins 5 and 6.

After my first attempt didn't work I did exactly this ... the IR detector, IR LEDs and transistor are only required when you actually want it to do anything !

Do double check your PIC programming ... I used ICProg which set the PIC clock to HS (High Speed). Make sure you're not using RC by mistake (all others should work).

Good luck :smile:

Robin

October 13th, 2002, 03:55 PM

Well ... I'm still having trouble with my Aiwa remote, adding ripple smoothing capacitors didn't help any. Judging by the issues that Bjoern is having, I suspect we've got the same problem.

Jon ... would it be possible to have a description of what the IR debug data stream represents ... I'd like to write an app that literally re-draws the wave-form on screen. Although I don't have a scope, I do think seeing the signal may be helpful.

Also ... why are there two boxes for codes within the Girder plugin ? Is this for the infamous RC5 ? If so, why do some of my learned JVC codes fill both code boxes ?

Robin

October 13th, 2002, 03:55 PM

Sandros - If I'm reading your post correctly, your cure consisted of removing a length of wire from between the COM port and the UIRT ?

Jon - Might the interference I'm getting be caused by unshielded cable ? If so, why do normally read codes seem unaffected ? I'm still not sure I understand why JVC codes are learned correctly whilst AIWA codes are not ?

Also ... the FF you use as a terminator ... What dictates that this is the end of the sequence ?

Did you try learning AIWA codes from your One-For-All remote ? If so, could you post your IR debug of the AIWA power button ? (and what the learned codes should be) Why are there two boxes for these codes ?

Robin

October 13th, 2002, 03:55 PM

Hi ... I just wanted to post thanks to Jon (again) for all his help with the problems I've been having, as I've now got my UIRT working successfully, which I certainly couldn't have done without his help.

Basically, my UIRT is based on Jon's schematic minus most of the capacitors and resistors ... mine works with resistors on the TX, IR LED & Transistor and a capacitor across the IR receiver only.

The problems I was having with "learning" remote codes appear to have been due to using unshielded wires to connect to the RS232 ... although it looked like everything was working properly, the learning side of the UIRT is much more susceptible to interference.

So I now have my UIRT built into my TV cabinet (where the HTPC lives), able to WOL, WOR and WOIR(!). As the HTPC is also my internet proxy, I added a Power LED to let me know when other PCs in the house WOL it and a switch (parallel to the transistor) to force shutdown should it hang (although I haven't needed it yet !)

Thanks again Jon for a very powerful tool and a lot of much appreciated assistance !

Robin

jon_rhees

October 13th, 2002, 03:55 PM

Hi all,

Over the last two evenings I have 'hacked' quite a bit on Ruud's stuff as well as the Girder Skeleton and Irman sources. If anyone is interested, here's what I've done:

1. I've modified Ruud's PIC code to make it work on a 4MHz part (so that I could use my existing HW). This modification makes the 4MHz parts act almost identically to the 10MHz code with the simple exception that the timing values from captured IR data represents 32uS increments instead of 25uS increments. This will make waveforms captured with 4MHz not playable (without some modicfication) on 10Mhz and vice-versa. Otherwise, the protocols all work the same, including 115200 baud rate, etc.

While making the modifications, I found a bug which is likely what Mark was experiencing--the Struct capture was sending out 32 bytes instead of the 20 expected. This was a simple error of the number '20' in the PIC code without the preceding '.' (needed to indicate decimal).

2. I found that my Panasonic IR codes use a 97-bit (transition) bitstream, and since Ruud's algorithm only captures 96 bits (12 bytes), I extended the packet to 16 data bytes.

3. I modified the Irman Girder sources to make it an extended plugin with the ability to sent codes to the UIRT as actions. This part is functional but the training (learn mode) is not complete. I know that Mark is working on this same thing, so I don't know if I'll put too much effort into it.

Anyway, that's what I managed to pull together in two free evenings. My reason for posting is mainly to see if anyone has interest in the 4MHz PIC code.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

There are only a few changes for the 10MHz code, and I can create a version with just these changes in it. Thes would include:

1. The buf fix about getting too many characters.
2. The extension from 12 to 16 bytes of data (I need this for Panasonic remotes, for example).
3. On this code and past UIR code from Ruud, I have changed the IR 'timeout' from 16mS down to 8mS. Unless I do, I have trouble getting some remotes to work.
4. I put in some extra timeout logic which helps give more robust performance with 'IR noisy' rooms (which can make some remotes appear to send differing codes when in fact they do not)

Other than changes 1 & 2, the protocol remains compatible.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

After a couple more evenings of coding, I've finally finished rev. 1 of both the UIRT firmware modifications (to Ruud's code) and rev. 1 of a UIRT Plugin which is based off of Ron's Irman plugin.

The UIRT plugin can be used as a replacement for IrMan, since it will support both UIR and UIRT hardware.

The Plugin has the following features:
1. Supports UIR and UIRT hardware
2. Selectable 'DROP DTR' option for different HW setups.
3. Ability to wait a specified amount of 'IR Inactivity' time before IR Transmission (to help avoid IR collisions)
4. Ability to cause Girder to block (wait) until IR Transmission is finished.
5. -or- Ability to generate a Girder event when IR TX is finished (good for long events like lowering volume to zero).
6. Ability to set # of TX repeats.
7. 'Learn' mode to capture a full (reconstructable) IR code.
8. Ability to Import 'Pronto' discrete IR codes (handy if you don't have a Pronto but want to use codes available on the 'net).

All I need now is to decide whether to get a real device code from Ron or distribute this first version with 240.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

I can confirm that TX works on the 4MHz parts ('cause that's what I'm using). If you are 'learning' from another remote, some tips:

1. When testing the learned IR code, try selecting different carrier frequencies as some equipment is very selective of this. The carrier frequency is NOT automatically set when you learn an IR code; only when you import a pronto code.

2. Verify that your learned code seems valid: Try learnin it a few times and verify the code that shows in the edit box is the same each time. You may find that the the the 2nd thru 7th hex codes (2 digits each) vary slightly between eac learn, but the rest should NOT vary.

BTW, which .HEX file are you using?

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Wykat,

I've sent you a private message regarding this issue...Please check it out.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

Assuming you are using the 16F84 part, this part contains 64 bytes of non-volatile EEPROM which the code can alter at run-time (albeit slowly).

Given that, perhaps the best way to deal with this from a software standpoint is to add a 'Write Code' button to UIRT which will allow a learned IR code to be written to the PIC's 64 bytes of flash which in turn could toggle/pulse one of the available I/O lines. This could even be expanded to allow several codes to be assigned to different I/O lines.

Thoughts?

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

OK, Tell you what I'll do...

First of all, I'll let you guys worry about how you want to do the hardware. There's about 100 viable ways to do it -- I personally would look to tapping off of the 'always on' logic supply used in the ATX power supplies (which is used for the power button logic, for example), and use a bilateral switch (simple) to go across the power button. This also buys you having a good power supply feeding the PIC, which means more available power for IR blasting.

Now back to the software--

I will add the necessary protocol to UIRT to allow 4 IR codes to be 'taught' to the UIRT. These codes can be programmed to do the following:

1. Pulse a selected I/O line (low-high-low) for a programmable amount of time (say 10mS up to 1 sec).

-or-

2. Set a selectied I/O line HIGH

-or-

3. Reset a selected I/O line LOW

You will be able to choose from one of Four I/O lines: RB1, RB2, RA0, and RA1.

How does that sound?

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

I'm figuring out my storage bits and have room for one of two options:

a. Each programmed code can Set/Reset/Pulse ANY COMBINATION of the 4 I/O's (i.e, a code can SET RB1 and RESET RB0 and PULSE RA0 all at the same time),

b. Each programmed code can Set/Reset/Pulse/Toggle ONE of the I/O's (this allows for all 4:set, reset, and toggle).

Which do you think is more desirable?

As far as anti-repeat, each code will also have a duration byte which affects the pulse duration. It also has the effect of masking any other code GPIO actions until the duration has expired (even when not pulsing)

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Actually, the GND is not really floating in Ruud's schematic...

Instead, he is 'cheating' by making use of the internal Shottky diodes on all of the PIC's I/O pins. In this case, the TxD line from the PC acts as ground through the 150 ohm resistor and then through a diode internal to the PIC's RB6 pin.

To get even more TX power, he asks that DTR be dropped during IR transmission which allows DTR to further act as ground (but without the 150 ohm resistance).

Personally mine is not wired this way at all, since I didn't want to scrounge up a transistor for level shifting. *but* I have a way to program parts externally (which most don't have).

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

Yes, my circuit is ground-referenced -- this is mainly because I have no need to program it in-system, and since I've had this circuit built for several years now running code I had written. I recently stumbled across what was being done here with the UIRT and decided to join in.

If you want to make your circuit ground-referenced, its simple. BUT, I haven't investigated what you would need to do to accomodate Ruud's programming applet, if you were trying to still program in-circuit with 12V from the power supply.

My circuit does a little cheating too, but it'll work in every PC design I know.

1. To derive power for the circuit, I run both DTR and RTS signals into anodes of two diodes. Then join the cathodes thru a resistor (say 300 ohm) then onto a 5.1V zener to ground. This gives me a 5V supply. If you have a separate 5V supply available, you can use this instead, since the resistor and the RTS/DTR signals are truly only going to give you 30 or so mA.

The incoming TxD pin from the PC can be run through a 10K resistor into the PIC's RX I/O pin. The RxD pin from the PC can be taken directly to the PIC's TX I/O pin. This works since even though RS-232 is +12/-12 signalling, any transceiver made in the last decade will also accept 0/5V signalling.

I wouldn't worry too much about Ruud's design and circuit currents--you'll never see more than 20mA per pin on RS-232, and they derate pretty quickly. On most transceivers, once you're pulling 10+mA, the swing is more like +7/-7 volts.

-Jon

P.S. Yes, the programming of the internal IR codes for the modifications I'm doing are being performed in the EEPROM area (*not* program memory). So, there is no need to have 12V when reprogramming that part.

jon_rhees

October 13th, 2002, 03:55 PM

Hmmm, that shcematic is very similar, and gets me to 'thinking'...

Yeah, the way you described it is correct -- basically the schematic you reference ir right with the exception that the port pins are different and match Ruud's. The only thing that would need to change is that the 1K off of DTR/RTS is too big. That needs to be lower, maybe like 330 ohm (unless you derive 5V from somewhere else, in which case you don't event need the diodes, resistor, and zener.

Now about the 'thinking' part...Do you think there's any interest in revising the PIC code further to work on this UIR design you've referenced? I think I see one spare GPIO which could be used for IR transmission. Obviously, such a design wouldn't support the extra I/O support we're adding...

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

an update...

I have nearly finished the software and firmware modifications to UIRT for the programmable IR codes and IO port control. I still have a few changes to make the PortB pins work OK (port A works fine, but PortB is messed with by a number of old functions in the UIRT firmware and these need to be modified).

The programming interface on the PC is also complete and is integrated as part of the UIRT plugin. This makes it simple to program and adjust parameters for these IR codes.

I am now going to add the ability to control these same port pins from Girder, as well as the ability to generate a pseudo-IR code action when PortB.0 is toggled as an input.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

genixia,

Hold on before you get too far with the 12V and MCLR. Let me correct a few assumptions.

1. During operation, MCLR stays 'HIGH' with respect to the PIC. (MCLR is active-low, and if LOW would hold the PIC in RESET). When RTS is HIGH (which is what happens when the PC's serial port is opened), the jumper J1 uses RA2,RA3,RA4 and cheater clamp diodes to the PIC's high rail. This limits the MCLR input to 5.7 volts or so. When Jumper J1 is removed, setting RTS high essentially puts a programming voltage of (ideally) 13V on MCLR, which is necessary for in-circuit programming.

If you choose to connect MCLR by another means, please keep in mind that it will need to be brought HIGH for UIRT operation, and need to be brought LOW when the serial port is closed (RTS goes negative), so that the PIC can be reset.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Genixia,

If you're planning on 'switching in' the 12V anyway, why not make it a 3-pin jumper to select between 5V and 12V and avoid the need for the low-drop diode?

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Nice part.

You'll find that a great many PIC parts would be suitable replacements. I have used a lot of 16x67x parts (even have one of 'em in my HTPC) which are similar (hardware UART).

I've been burned a bit by the HW UART, and mybe Microchip has finally fixed it in these new parts. Many of their current parts have data RX loss problems when using the HS (high-speed) mode, which is necessary to usually hit the higher baud rates with accuracy.

As far as the internal 4MHz. I've used this before on other PIC parts, and you have to keep in mind that it is *not* a crystal or resonator inside, but a trimmed RC circuit. I pulled up Microchip's data sheets (which, BTW, still say 'Preliminary'), and the typical ~3.7 to ~4.3 MHz with 4MHz nominal is listed. This may make it a little too loose for RS-232 communication.

I've used th comparators (which are also on the '622 part) before on an automatic Treadmill with good results. My all-time favorite part is still the 16x71 (one of the first with A/D and UART).

Anyway, my point is that a great many PIC parts should be usable with little modification to the .asm. All of the modifications I am adding are set up with contants and #defines such that they can be changed without too much effort.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

jediperry,

Nope, I always stuff a few transistors in to serve as inverters. Yet another drawback from moving away from the 'arcane' method of bit-banging.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

ACClarke,

You're going to have to be more specific now...there's now 2 plugins and 2 UIRT firmwares floating around...and I don't believe they're compatible!

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

ACClarke,

Can you go into more detail about the RC5 problem? The UIRT firmware I have been modifying originated from Ruud, and I thought it had RC5 logic in it...

Could you please explain?

Thanks!

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

ACClarke,

Please confirm:

1. You are trying to RECEIVE IR codes from these remotes, and are looking at the IR events displayed in Girder.

2. What version of HEX file are you using. Are you using this same hex file for VirtualRemote?

3. What speed PIC are you using?

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

ACClarke,

I just looked at the code Ruud wrote for VirtualRemote DLL (that's what you're using, right?) and saw that he is receiving IR codes in 'Structured' mode. Currently, my UIRT plugin still receives IR codes in the original 'UIR' mode, which are 6-byte codes, whereas the structured codes are much longer. So, are the codes you see in VirtualRemote 20-21 bytes long?

It is not clear to me why structured mode would receive codes and UIR mode would not. When using the UIRT plugin, do you get anything at all from your Akai remote???

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

ACClarke,

Have you tried defining a command and then going into the 'Settings' for that command and hitting the 'Learn' button? Please try that and see if you can learn a code. If so, please send it to me...

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

The final step I still need to perform on this new rev. of the UIRT code is to handle PC standby/resume, etc. This is normally not a problem, since the UIRT plugin is normally set to be disabled in such events, and would lose power and hence need to be reinitialized when the plugin starts back up. I am trying to work out a scheme where the plugin when started back up can detect if the UIRT is already initialized. This is necessary for those who will be powering their UIRT all of the time.

I also need to change from the concept of 'initialize' to 'query', since I need the UIRT to be operational even when its first powered up, rather than waiting for an 'IR' or 'IT' command from the host.

Anything I'm missing here?

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Danijel,

Thanks for doing some testing. Please clarify some of your statements:

"This is how raw data looks (32bit remote space coding).
71 32 14 10 22 10 14 10 ..... <- from girder"

--Where did you copy this data from. Could you describe the process?

"142 68 10 7 10 24 10 7 ..... <- real remote"

--Where is this data from?

Thanks!

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Danijel,

Thanks for the response. I have already discovered the bug in 10MHZ version which causes learned codes to be transmitted at twice their normal speed. This bug was in Ruud's original code, since the RAW mode (which is what I use for learning) was in units of 50uS and when transmitting I use STRUCT mode, which expects units of 25uS.

I already have a fixed version of this which I previously sent to ACClarke to try. If you can give me a way to send it to you to try too...

In your previous posts you say that you you cannot learn 32 bit remote with 4MHz. I assume you mean that you cannot get the 'Progress Bar' on the learn dialog to advance? Could you please send me the entire 'Real Remote' code of one of the buttons (captured by your RemoteView)?
Hopefully that will help me discover why it cannot learn on 4MHz and transmits short on 10MHz.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Genixia,

In your circuit, please make sure you have the ability to leave MCLR 'high' all the time (even when the PC is OFF). Keep in mind that the PC Serial port will sink all of its outputs to Ground when the PC is off, and if MCLR is held LOW, the PIC will not be able to continue to receive IR codes and toggle port pins, etc.

The caveat with simply tying MCLR high is that the unit will no longer act like a true UIR. Also, you'll have to make sure the 16F84 has built-in power-up reset capability.

You could make a fancy circuit which controls MCLR from RTS but ONLY when the PC Serial Port is powered...

As far as the RA2,RA3,and RA4 lines, they are not used in code. The way the new Port pin control code is written, these can easily be added as more output pins which girder can control -OR- input pins which can generate girder events.

Any pins you designate as inputs, you'll want to have a pull-up on-board to keep from floating.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Danijel, ACClarke

I have posted version 1.1 of both the UIRT plugin and the 4MHz and 10MHz PIC code.

they can be found at:

http://www.geocities.com/jon_rhees/UIRT/

I would appreciate if you could give it a try--specifically this new version has a very small button which will appear between the 'LEARN' and "TEST" buttons. If you press this small button, the UIRT plugin will capture a key on your remote in RAW mode and place it in a text window which you can cut and past back to me.

Danijel, I would appreciate if you could perform this with the same button you sent me the raw data for. In addition to the raw data in UIRT, could you also paste the learned 'Value' which appears after pressing the 'LEARN' button (use the 10MHz).

ACClarke, I would appreciate if you could capture the raw data for one of the buttons you are unable to learn.

Thanks!

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Danijel,

Oops! You found a bug in the 10MHz build. I have rebuilt it (it was using some of the 4Mhz modifications). It is at:

http://www.geocities.com/jon_rhees/UIRT/U24v11a.zip

Please give that one a try.

As for you not being able to see any progress on 32-bit remote on 10MHz -- Ruud's code does not terminate an IR code unless it sees 13mS of silence after the code. I wonder if the 32-bit remote repeats too quickly and this is not working?

Is there a way you can tell me the amount of space between transmissions?

You can also test this by using the small button again, but instead of holding the Remote button down, try pressing it repeatedly and see if you can get the progress bar to move...

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Danijel,

WOW, I have never seen a remote with such a long header (AGC) pulse! My code (based on Ruud's) performs all measurements in 25uS resolution. This means that the maximum pulse size currently quantifiable in a byte is about 6400uS. The header pulse on your remote is almost 9000uS!

I will have to think about how to correct this... I am hesitant to decrease resolution because I also have remotes that have very SHORT space/pulse spacing (my Panasonic remote has pulses only 150uS wide but yet has over 64 bits to send).

Let me think about it...

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Danijel,

Yeah, my remote is one of the fastest I have found. Its a special make for HDTV's and STB's. I am able to easily verify all timing since I have a storage scope. This is also why I made 4MHz code do 115,200 baud to keep up.

I think I will try changing all timing values (4MHz and 10MHz) to 50uS resolution. I had picked 25uS because that is what Ruud was using for 10MHz plus that is what Pronto remotes use (though they encode timings in 16-bit values).

I will make those modifications as well as the ability to send RC5 codes for you to try soon.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Danijel,

I have posted a test version of the hex files which uses 50uS timing and should be able to learn/play back the 32-bit remote. Please give it a try. I appreciate it.

It is at:

http://www.geocities.com/jon_rhees/UIRT/U24v11a50.zip

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Danijel,

Have you had a chance to look at the 50uS version of the PIC code? I have tried the 4MHz version with my equipment and it works fine (other than I had to adjust all the codes I have already learned).

Also, I managed to find a manufacturer code for my remote which transmits RC5. I know that RC5 consists of 14 bits -- 2 start bits (always '1'), a 'T'oggle bit, 5 Device Address bits, and 6 Control bits. However, I was surprised to find that the 'T'oggle bit only changes on each successive Press of a button. I was expecting it to change on each code transmission (i.e., if I held a button I though it would continuously toggle).

Based on this information, I believe your TV/etc. should still respond to an RC5 IR transmission from Girder even if the toggle logic is not in place. I know that it wont toggle on each TX, but consider this:

What if you:
1. Take your TV remote and point it at the TV and press a button.
2. Point your remote away from the TV and press the button again.
3. Point the remote at the TV again and press the button again.

Does the TV respond in steps 1 and 3? (Both of these steps will be transmitting the exact same code).

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Yes, there are at least two UIRT designs going on. I can speak for the one I am working on. It is based on original firmware written by Ruud and has been overhauled quite a bit to add support for 10MHz and 4MHz PICS as well as totally new support for controlling I/O pins on the PIC with IR commands even when the PC is turned OFF. I have written a UIRT plugin to work with this design, and both are in a semi-release, semi-development stage. I currently use this on my HTPC and I am aware of a few attempting to use it with mixed results. The bulk of the development left on this design is accomodating all brands of remotes (this should work in theory, but we're finding some surprises). I am also aware of (as you'll see in this thread) development going on in the hardware arena to make a board to facilitate the new I/O pin functionality.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

I will be posting version 1.5 of my UIRT firmware and plugin soon. Many changes have been made, and I can confirm it should work for your Sony equipment (I have several Sony components), if you want to give it a try. The only thing not tested is the 10MHz firmware, as my hardware is using the 4MHz firmware.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Version 1.5 is now posted at http://www.geocities.com/jon_rhees/UIRT/UIRT_1_5.zip

I will also be sending it off to Ron for posting in the download section.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Sandros,

Please post your results with the 4MHz XTAL. As I have indicated before, I haven't tested the 10MHz firmware and there have been dozens of modifications to it. The 4MHz is tested, though, and is in use by several. I am aware of others who have hit-and-miss results with deriving power from RS-232, but first I'd like to know your results with 4MHz.

You won't want to remove the 10 ohm since this will basically shunt all available supply through the LED's which will likely reset your PIC. Also, lowering the 150 too much can cause the RS-232 outputs to current-limit mode, and raising it too much will not give enough supply capacity to the circuit....etc.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Sandros,

One other question:

When do you get the 'NO ACK' error -- when you try to learn a code or when you try to IR transmit. Are you able to learn codes, etc?

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Sandros,

Do you still get the 'NO ACK' with the UIRT_4MHz.HEX code and the 1.5 plugin?

Jon

jon_rhees

October 13th, 2002, 03:55 PM

Sandros,

One more question:

1. Do you have 'Drop DTR @ Tx' checked in the settings? (You should if you're using Ruud's schematic)

Jon

jon_rhees

October 13th, 2002, 03:55 PM

Sandros,

A few more questions:

1. When you press F5, about what percentage of time do you get 'ERR 80'/etc., versus 'IR command sent'

2. In the settings for the IR code, make sure your repeat count is set to about at least 4 (for Sony) and Carrier is set to 40KHz (for Sony).

See if that improves things...

-Jon

P.S. Err 80 indicates the UIRT hardware detected a checksum error from the data it received from the PC. This would indicate a communications integrity problem.
[ This Message was edited by: jon_rhees on 2002-01-03 22:50 ]

[ This Message was edited by: jon_rhees on 2002-01-03 22:54 ]

jon_rhees

October 13th, 2002, 03:55 PM

Sandros,

I'd be interested in knowing if you get the 'Err...' messages yet the VCR still responds. In other words, if you press F5, do you see 'ERR No ACK/etc' and the VCR powers off/on?

If so, this would indicate that the command made it to the UIRT hardware fine, but it is having trouble sending the response, which may be due to the power supply sagging too much.

The baud rate is 115200, and therefore may start giving you trouble after 20 feet. It may be even shorter than that because we're power stealing.

As far as the repeat setting, it is normal to need more than 1. The way most remotes work, an IR code is repeated as long as you hold the button down. A typical user keypress will send several repeats before the user lets up on the button (its even difficult to press the button quick enough for only one code). Many devices look for multiples to improve error rejection.

Jon

jon_rhees

October 13th, 2002, 03:55 PM

LLoyd,

Sorry, but I suspect that the 10MHz code is broken. I am currently in the process of getting a 10MHz setup so I can keep both sets of code functional. I expect to be there in another week.

Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

is anyone trying to use the 1.5 firmware (from myself) with Ruud's PCB design??? I just noticed that his PCB design does *not* match his schematic, and that on the PCB pin 17 (port a.0) is tied high and pin 18 (port a.1) is tied low. This will be a problem for later firmware with I/O control capability, as these I/O lines are set to OUTPUTS!

If anyone is in this situation, please let me know!

Thanks,

Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

Here is some observations after analyzing some issues I am having with the non-ground-referenced (Ruud's design) UIRT.

I would very much like to see this method operational, since it allows in-circuit programming, and unlike us that have a PIC programmer sitting around, allows firmware updates.

However, as you'll see in the observations, I see a majority of PC's not being able to supply enough voltage for robust operation.

I know a few have measured their supplies too and the results aren't promising. I'm looking for ideas!

-Jon

Problems encountered with Ruud design:

1. Supply Voltage too low…
a. After testing with several PC’s (to see variation in Serial Ports), I found that the power supply derived from the PC’s TXD line is having difficulty producing an adequate supply for the UIRT circuit. Since the supply voltage is dependent on TXD’s negative voltage, I measured the PC’s TXD line (referenced to PC’s GND, which is the UIRT’s V+) as well as the voltage after the 150 ohm resistor. The average voltage for these was 4.8 and 3.8 volts, respectively. Now it is important to note that event though there is –3.8V measured after the 150 ohm resistor, this does NOT mean that the PIC or other circuitry (the IR detector) is seeing this voltage. For this –3.8V to become the negative rail for the UIRT depends on the internal Shottky protection diode on the PIC’s RB6 pin. This is also evident by measuring the voltage across the IR detector, which measures just below 3.1V. This is just as expected, because the saturation voltage for these protection diodes is typically 0.7V.
i. This is a problem for the IR Detector, which is rated at 4.5 to 5.5V operation. In my experience, I have found these IR detectors will work at lower voltages, but tend to become noisy or begin to send out false triggers since their power supply rejection (PSRR) drops off at the lower voltage. See item #2 below.
ii. This may also be a problem for the PIC. In my testing, I did not see the PIC suffer stability problems. However, the 16F84 and 16F84A are rated to operate only down to 4.5V (The 16L series can go down to 2V, or 3V at 10MHz). In addition, we can expect the supply to sag somewhat during PC TXD transmission, which leaves us no breathing room.
I was a bit surprised to see TXD’s negative voltage only pushing 4.8V at a 6mA draw (the 6mA is determined by taking the drop across the 150ohm resistor and dividing by the resistance (1V / 150ohm = 0.006A). However, keep in mind that many integrated RS-232 drivers nowadays generate their own voltages using a charge pump, and they tend to concentrate on slew rates more than pushing a static voltage.
Update: I found desktop computers to fare better on this test. A Dell desktop PC pushed as high as -7.5V on the TXD line, and as expected, 5.1V (limited by the Zener) was measured across the IR detector’s supply. However, I found other desktops barely pushing -5V on the TXD line. Another thing worth noting is that the UIRT circuit runs more efficiently (pulls around 2-3 mA) when properly supplied with 5V – unlike the 6mA it pulls when only getting 3V. This is very typical of MOS-based circuitry.

2. IR Detector activity during PC TX
a. This was a surprise which caused a LOT of stability and robustness issues with the UIRT circuit. In a nutshell, I found that whenever the PC sent a byte of data (via TXD) to the UIRT, the IR detector’s output would go LOW (indicating IR activity) for nearly 1 mS or more. Before delving to find out why this is happening, one should understand why this would cause a stability issue: Since the UIRT is based on a simple PIC microcontroller without an embedded UART, the PIC code must manually transmit and receive serially on a bit-by-bit basis. Therefore, it cannot transmit and receive simultaneously nor can it receive while doing other major tasks. Therefore, when IR activity is detected, the PIC immediately begins concentrating on decoding the IR signal and no longer accepts received data from the PC. So, a race condition has arised from the IR detector falsely firing when the PC starts to send data. In about 80% of the time, the IR detector would false-fire before the PC’s byte had even finished transmission. Therefore, the PIC would begin decoding IR and the PC’s command would never be seen.
Now on to why this is happening:
i. I first verified that this was a power supply issue by disconnecting the output pin from the IR detector (no longer went to the PIC) and also disconnecting the IRLED’s (just in case they were somehow transmitting). Sure enough, the problem persisted.
ii. With the supply to the IR detector and the output pin from the detector both hooked to a scope, I was able to verify a very minute drop in supply voltage which appeared to trigger the IR detector. This is not a surprise, since the detector is running far below its spec’d operating voltage.

3. Inconsistent power-up RESET
a. I believe this problem is simply related to a low supply voltage.

jon_rhees

October 13th, 2002, 03:55 PM

Well,

I'm basically putting this question back at you (all),

I basically vote for the external supply. You can easily steal 5V from the keyboard connector, but this doesn't solve the +12V needed for programming. (BTW, I can program my PIC about 50% of the time successfully, even though the PIC is only getting ~9V).

I know Genixia was working on coming up with a HW design. I don't know if that has been indefinitely put on hold or what.???

I'd be glad to propose a HW solution as well.

My basic desire is to produce a stable plugin, and if need be, a HW design to take advantage of it.

I have been working with this design for several hours now, and I simply cannot achieve the stability I see with either my externally-powered circuit or my DTR/RTS-powered circuit (ground-referenced).

Granted, even my RS-232-powered circuit which relies on DTR and RTS doesn't get a full 5V when running on a few PC's (although notably it does fare better -- probably because charge-pump-based RS-232 transmitters are more efficient at generating the + supplies?), it doesn't suffer the IR detector instability, most likely because RTS/DTR don't toggle/go away when the PC needs to talk.

Even on a PC when supplies are high enough, I find that when the PC wants to do a IR transmission, it has to send 24 bytes of data to the PIC. That's a low of data to be intermittently taking TXD supply away from the UIRT. Of course, that's what the capacitor is for, but if your supply is only averaging 50% duty cycle for a time, you can expect the voltage to drop. If it does drop below 5.1V at the zener, the supply is now unregulated again, and hence the IR detector complaining.

Jon

jon_rhees

October 13th, 2002, 03:55 PM

All,

I have posted a preliminary version 1.6 of UIRT and Plugin at:

http://www.geocities.com/jon_rhees/UIRT/UIRT_1_6.zip.zip

This fixes the broken 10MHz firmware as well as makes a few changes to serial communications to hopefully make the Ruud-based designs behave better.

This also fixes a bug with the PIC I/O pin control.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Robin,

I have posted a schematic which will do what you need. I plan to create several version of schematics for other needs as well. The schematic is found at:

http://www.geocities.com/jon_rhees/UIRT/PCPoweredNoICSP.GIF

I built this particular schematic today and hooked it up to a Dell Desktop to verify that it could successfully be set up to power-up/power-down the PC via IR remote control.

A few connections might need explanation:

1. '5VSB' stands for the ATX-standard 5V standby power supply. This is required from all ATX power supplies and is typically supplied on the PURPLE wire coming from the power supply.

2. 'PC GND' can be connected to any ground wire on the PC (just pick a black wire from the PS, for instance).

2. 'PCPWRBTN' will be the signal going from the power button on the front panel to the motherboard. On most ATX boards, there will be a two-pin PWR connector that this button hooks to. This schematic will work with those which tie one side of the button to GND and the other is pulled up on the motherboard to a voltage derived from 5VSB (typically 3.3V). Use a meter to determine which pin is which. If you measure voltage between GND (use the PC case is easy) and each pin, you'll find one of the pins always sits at GND while the other will show 3.3V and be at GND when the button is pressed. 'PCPWRBTN' should connect to the latter.

For my testing, I bought a few of those 'wire taps' which allow you to splice a wire onto an existing one.

Jon

jon_rhees

October 13th, 2002, 03:55 PM

Lloyd,

If you have trouble getting to the schematic, try going to http://www.geocities.com/jon_rhees/UIRT

You should then see the schematic and code.

I think geocities does something funny when you try to go straight to a link.

Genixia,

Keep in mind that some may not want to use the WOL approach, but may choose to hook into their PC's power button. This has the advantages of working with a wider range of PC's and also invoking a quick PC shutdown or even an emergency shutdown.

aderusha,

No offense to any pursuing making this into a PCB, but I have found through many years that often having a PCB is the *long* route to a solution. If you run across a schematic that you need to only build 1 of, and you might have need for a little customization, I find it simpler to wire up the circuit using though-hole parts on a protoboard.

I use wire-wrap wire but *do not* wirewrap. In other words, I use wire-wrap wire to solder between points on a standard protoboard (the kind with copper eyelets on each hole).

I often even use the cheapo stuff from Radio Shack since its a local store.

Yes, I would say it takes about 50% longer to build one of these up than if I had a PCB, but the nice thing is that if I have the parts, I can have one running *today*. Also, if I need to vary from the schematic, its easy.

Yesterday I built up the schematic I posted from scratch in under an hour. I used standard parts (except for the PIC and xtal), and put it on an off-the-shelf protoboard which measures 1.6x1.6 in., with room to spare.

If others are interested in this approach, I could scan images of the top/bottom of such a board and then you wouldn't even have to think about where to hook the interconnects.

Just a thought...

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

aderusha,

First thing I would look at if you have any type of scope is the xtal. Verify it has indeed started up. BE CAREFUL, though! Since Ruud's design is not ground-referenced, you do NOT want to habitually connect your scope's ground clip to the UIRT's ground. Instead, connect it to the PC's ground (which is the UIRT's V+). You'll just see everything on the scope happen below GND level, that's all.

If that's working, the next things I'd check are:

Check TXD from the PC at the PIC pin 12. Verify that when you hit F9 in Girder to try enabling plugins that you see activity on this pin.

Then, if that looks good, check RXD coming from the PIC to the PC on PIC pin 13. The PIC should respond during plugin initialization (at least with my plugin, I query the PIC during init).

Jon

jon_rhees

October 13th, 2002, 03:55 PM

Lloyd,

This, I found is due to the fact that an unitialized serial port usually has DTR LOW (negative), which helps supply voltage on the UIRT for Ruud's design. Unfortunately, DTR must be brought HIGH for data to be received from the UIRT. We *do* bring it low during an IR transmission to help drive the IRLED's, but if a serial port can't run the basic UIRT when not transmitting without the help of DTR, you're out of luck (as you've seen).

BTW: I have found that the IR detector I am using (which is spec'd to run 4.5-5.5V) will *sometimes* run at 3.5V and *sometime not*

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Sandros,

There are 1001 ways to supply power externally, and the best for your needs really depends on your situation.

1. If you really need true external supply, the easiest is probably a wall-brick transformer (9-12VDC) plus a LM7805 regulator IC and a few capacitors.

2. If you're already connecting to a PC, it may be simpler and more elegant to steal 5V from the PC. If inside the case, steal it from a drive power connector (red wire). If outside the case, steal from the keyboard connector, etc.

I do *not* suggest batteries. Although they seem simple enough, keep in mind that this circuit will draw several milliamps 24x7.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

aderusha,

I have posted a schematic for a simple 5V regulated supply. You should *not* just connect a 9V battery to UIRT as it will probably destroy the PIC and IR detector (voltage too high!).

The schematic is at:
http://www.geocities.com/jon_rhees/UIRT

Then click on the file 'simple5V.GIF'

Note that the schematic uses a standard wall transformer -- the kind used for just about all AC-powered electronic equipment these days. Look for one with 9VDC output, at least 100mA. You're okay going a higher voltage, but avoid going above 12V as the regulator will dissipate too much heat.

Make *sure* the transformer outputs DC! and observe polarity!

The four capacitors in the schematic are to ensure a clean supply and avoid local oscillation. You may get away with omitting the 100uF caps, but I wouldn't leave off the 0.1's...better safe than spending a lot of time later chasing your tail...

You may want to build this power supply circuit up first, and test it on a meter. If you get 5V out, you're all set :smile:

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Robin,

If I were you, I wouldn't derive your 'power' LED status from the serial port, since this will act funny if you're booting a machine and also when coming our ot standby, since the LED won't look right until Girder restarts all the HW plugins. The lag in time can be very confusing. Since you're already running wire to your PC, just add an additional wire and your cable and hook it to the *real* 5V in the PC (not the 5VSB). Then, connect a LED and resistor between the 5V and 5VSB (anode towards the 5VSB).

Jon

jon_rhees

October 13th, 2002, 03:55 PM

Robin,

The RS-232 spec is indeed 12V. However, RS-232 transceivers over the years tend to create their own voltages now with charge pumps and usually drive less than 9V. The RS-232 receivers in PC's will usually work fine with 0-5V swing, too.

XTAL vs. Resonator. Good question. I have 3 circuits -- 2 use a 10MHz XTAL (without caps, although adding the caps can never hurt), and one 4MHz which happens to use a resonator since I had one lying around. I believe I have the config bits set for XT (Xtal). If you have access to a scope, you may want to verify that the xtal is oscillating.

The UIRT plugin (versions 1.5 and back) can run in UIR mode. Version 1.6 cannot since I hardwired the 'Enable UIR Mode' checkbox to ON.
However, if you want to use two instances of the same plugin, you would have to have a special version created which used a different device ID.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Robin,

You really *should* put in a 1K or higher resistor on the PC's TxD line (if you haven't). This acts as a current limit since the PC will try to drive this TxD line negative and the PIC will end up shunting all the negative voltages with its protection diodes.

Jon

jon_rhees

October 13th, 2002, 03:55 PM

'Cannot read 1st char' is a catch-all error message that basically says the plugin isn't seeing *any* response from the UIRT.

If you get this all the time, I would make sure that you have the right COM port picked in Girder.

If you receive this occasionally, there's a good chance that the circuit is not seeing a proper reset. This can be due to the way some serial ports behave when the COM port is closed (not open). Since Ruud's design powers from the serial port, sometimes the circuit power-up ramp can be slow on some serial ports. Completely rebooting can often solve this because the computer resets the COM port and gives the UIRT time to discharge.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Wintermute,

Can you please confirm after all of your changes that you indeed need the Rs-232 loops you described?

I have not experienced this, and in all my designs I do not loop these signals. Perhaps there is some default in flow control I am not overriding in the plugin...but I would like you to cnfirm since I cannot duplicate this...

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Robin,

It is very likely that you are experiencing this because of a 'noisy' UIRT. The best way to know this is if it gets stuck in learning mode and you see a ton of girder events pouring in (see codes coming in on the Girder status bar) even though you're not running your remote. Is this what you're seeing?

If so, the first and foremost thing you'll want to do is try to quiet down your UIRT. This requires an RC or LC at the IR detector, since the IR detector is what will be producing this noise.

Here's what happening in this case.

1. In regular 'run' mode, I have put in a lot of code to try and filter this IR detector noise. The IR detector employs a AGC circuit which automatically adjusts itself to an incoming remote control code. But, when there is IR 'silence', the detector should also be quiet. A noisy supply to the detector will cause it to start spitting out garbage at this time since the AGC has nothing to track.

2. In 'learn' mode, the UIRT basically sends *everything* to the PC. So, if your UIRT is noisy and gets stuck in learn mode, you'll see a lot of events coming into Girder. Another way you can see if its noisy is to put a scope or logic probe on the IR detector's output pin. In a clean circuit, it will not do *anything* when an IR remote is not sending to it.

3. Due to the current design of the UIRT, it can only send or receive, not both, via the RS-232. So, when it is busy getting IR data, it cannot listen to the PC. A noisy UIRT will make it very hard for the PC to get in a 'Go to RUN mode' command edgewise.

There's a couple of things I'm thinking of changing for this.

One is to basically reset the UIRT to get out of learn mode. The other is to change the UIRT firmware to switch to 'listen to PC' mode even if IR reception is in progress. This has other implications though.

One thing you can try if your UIRT is noisy that may help is to try to block out as much light as possible while you're learning. Try covering up your circuit with a folder or something and placing the remote under the folder as well.

Jon

P.S. I have to agree on the USB issue. Although I've developed USB interface devices before and could do it again, it would prohibit the 'average Joe' from building it.

jon_rhees

October 13th, 2002, 03:55 PM

Thanks for the replies.

Wintermute, I'll look at the plugin and verify that I am specifying to NOT use flow control.

Robin,

Please, when you get a chance, I would like more detail. Specifically: a) exactly what the read error message reads, b) you say after the third match -- exactly what do you mean -- the third learn attempt, or what (you should hold the remote button down, not press repeatedly). c) doeas Girder hang?, etc.

Thanks!

Jon

jon_rhees

October 13th, 2002, 03:55 PM

FWIW, here's what the code reads for setting up the COM port. This part of the code was originally written by Ron B.

-Jon

sprintf(buffer, "baud=%d parity=N data=8 stop=1 to=off xon=off odsr=off octs=off dtr=on rts=on idsr=off", rate);

if (BuildCommDCB(buffer,&dcb)==0)
{
return FALSE;
}

dcb.fAbortOnError = 0;

if (SetCommState(com, &dcb)==0)
{
return FALSE;
}

jon_rhees

October 13th, 2002, 03:55 PM

All,

Here are the pictures of the proto-board I made up sometime last week. As stated before, this was designed to test control of the power switch on a PC, and is not currently wired to send IR signals (so no IRED's or 10 ohm resistor). This could easily be added. Also, this circuit is using a IR detector from Radio Shack (not the best, but was handy).

Some differences from the schematic you may note:

1. There is no 1K resistor between power and ground to help drain charge in the circuit for faster power-on resets.
2. There is no 10K pulldown on the TX line from the PC in case the rs-232 connection is removed.
3. I am using a 10-pin header to connect to the RS-232 cable. I had a male DB-9 RS-232 to 10-pin cable lying around. These can be found on old PC serial cards, etc., but note that their pinouts may differ from the one I used!!!
4. The collector on my 2N3904 transistor isn't going anywhere, since I removed the test wire to take this picture.
5. I used a 2-pin connector to route 5VSB and GND into the board.
6. I used a slightly different power filter on the IR detector. I used a ferrite is series and then both a 33uF and 0.1uF to ground.
7. Power coming into the board is filtered with a 47uF and a 0.1uF (hiding beside it).

Most of these changes are simply due to parts I had lying around...

The pictures can be found at: http://www.geocities.com/jon_rhees/UIRT

They are UIRT_5VSB_top.jpg and UIR_5VSB_bot.jpg

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Robin,

If I read your post correctly, you are having trouble 'learning' (so you can IR transmit) on the AIWA remote which causes all of the 'hanging' problems with the plugin, etc. But, you *can* learn your JVC remote. Is this correct?

Is it also correct that you can receive IR codes (girder events) from the AIWA OK?

If this is the case, it is very possible that the IR Learning algorithm in the UIRT plugin is having a problem with the AIWA remote protocol. This I will need to look into. Here's what I need you to do in this case:

1. Go to the screen where the 'Learn' button is located, but instead of pressing the 'Learn' button, press the 'IR Debug' button. Then, hold down a key on your AIWA remote until the progress bar goes to 100%. You should then be presented with a dialog full of number strings. Simply copy and paste the contents of this dialog to me (email is jrhees@proxim.com).

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

bjoern,

If you get a chance, I would appreciate a 'debug' dump from my UIRT plugin on one of the keys on your Sony Remote. The only thing I can figure is that your remote is different from the 'standard' Sony -- since almost all of my equipment is Sony and I control it without problem.

To do a debug dump, use the 'IR Debug' button in the plugin. Simply click the button and then press and *hold* a particular button on your remote (hold about 1 foot or more away). When it is done, a dialog will pop up with a whole bunch of hex numbers in it. Simply copy and paste this to me in an e-mail (jrhees@proxim.com).

Best regards,

Jon

jon_rhees

October 13th, 2002, 03:55 PM

bjoern & robin,

I have seen both of your debug captures, and you are experiencing completely different problems. Here is a clip of bjoern's capture:

A3 92 04 35 02 15 02 20 02 15 02 15 02 20 02 21 02 14 02 15 02 20 02 15 02
20 02 21 02 20 02 15 02 15 02 20 02 15 02 15 02 20 02 FF
01 02 04 36 02 15 02 20 02 15 02 15 02 20 02 20 02 14 02 15 02 21 02 14 02
21 02 21 02 20 02 14 02 15 02 20 02 15 02 15 02 20 02 FF
01 02 04 36 02 15 02 20 02 15 02 15 02 20 02 21 02 14 02 15 02 20 02 15 02
20 02 20 02 21 02 15 02 15 02 21 02 15 02 15 02 20 02 FF
01 02 04 36 02 15 02 21 02 15 02 15 02 21 02 20 02 15 02 15 02 20 02 15 02
21 02 20 02 20 02 15 02 15 02 20 02 15 02 15 02 21 02 FF
01 02 04 36 02 15 02 21 02 15 02 14 02 20 02 20 02 15 02 15 02 21 02 15 02
20 02 20 02 20 02 15 02 15 02 20 02 15 02 15 02 20 02 FF
01 02 04 36 02 15 02 20 02 15 02 15 02 21 02 20 02 15 02 15 02 20 02 15 02
20 02 21 02 20 02 15 02 15 02 20 02 15 02 15 02 20 02 FF
01 02 04 36 02 14 02 21 02 15 02 15 02 21 02 20 02 15 02 15 02 20 02 15 02
20 02 20 02 20 02 15 02 15 02 20 02 15 02 14 02 21 02 FF

And here is a clip of Robin's:
AB C4 B4 02 06 53 0C 02 05 02 10 02 06 1A 0D 02 06 1B 0D 02 06 1B 0C 02 05 03 0E 21 0C 02 05 03 04 15 0C 02 06 05 0D 02 05 05 0C 03 04 04 0D 04 06 03 0C 02 05 03 0F 0B 0D 03 04 1B 0C 02 06 05 0C 02 05 03 0E 02 04 07 0C 02 05 03 04 15 0C 03 04 04 0E 02 05 03 0F 21 0C 02 05 03 04 16 0C 02 05 03 04 15 0C 02 06 1A 0D 02 05 03 04 15 0C 03 04 1C 0C 02 05 03 0E 0B 0D 02 05 03 0E 0D 0C 02 06
04 0D 02 05 03 0E 02 05 03 0F 0C 0C 03 04 02 05 02 05 03 04 0A 0C 02 05 03 04 15 0D 02 06 1B 0C 02 05 03 04 16 0C 03 04 03 04 16 0C 02 06 1B 0C 03 04 02 05 02 05 03 04 0A 0C 02 05 03 04 15 0C 02 05 02 05 03 04 FF
01 AA B4 5A 0C 02 05 03 05 03 04 FF
07 3E B4 03 04 55 0C 02 05 02 05 03 04 FF
07 3E B4 02 04 56 0C 02 06 FF
07 53 B3 02 06 53 0D 02 05 03 04 FF
07 53 B4 02 04 56 0C 02 06 FF
07 53 B4 5A 0C 02 05 03 04 FF
07 53 B4 02 04 55 0C 02 06 FF
07 53 B4 02 04 03 04 50 0C 03 04 02 05 03 04 FF
07 3E B3 03 04 55 0C FF

The capture from Bjoern is what a sequence of IR codes *should* look like: repetetive and consistent. The problem with bjoern's remote working has to do with the fact that the inter-code spacing is almost right at the threshold programmed into the code.

Robin's capture is suffering from some sort of noise/etc. issue, which is causing inconsistent data to be received.

Here is the format for the data (very simple).

The first 2 hex digits represent the amount of time (in 50uS units) since the last code.

Codes 3..n are pairs of values which represent the 'ON' time followed by 'OFF' time of the IR modulation.

The sequence ends with a terminator (FF) code.

So, a line like:
07 53 B4 5A 0C 02 05 03 04 FF

means 0x0753*50uS since last code, with code contents: ON for 0xB4, OFF for 0x5A, ON for 0x0C, OFF for 0x02, ON for 0x05, OFF for 0x03, and ON for 0x04.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Sandros,

There are two boxes for compatibility with remotes that send two codes each time a remote button is pressed. This happens on several brands where when you press a button, code 'a' is sent once followed by code 'b' being sent repeatedly for as long as you hold the button.

The Pronto remote records two codes for each learned code as well.

The learning algorithm will determine if two codes are necessary, and if so, will fill in both boxes. If you find that box 'b' occasionally fills up, its often an indication that you got a noisy reading and should learn again.

-Jon

P.S. Cable length *shouldn't* affect UIRT (unless you're talking over 12 feet), but *can* if you have not properly decoupled your circuit. Make sure you have proper decoupling capacitors on your circuit, since it is deriving its power source over a distance. Also, keep in ming that you should really use a shielded cable, since RS-232 signal drivers are not being used and therefore you're asking a lot for 115,200 baud over a cable with wimpy MOS drives.

-Jon

jon_rhees

October 13th, 2002, 03:55 PM

Robin,

You're welcome! Its good to see others are able to benefit from this.

pz,

Actually, I had discussed making the UIRT support the '628 series. The modifications required should be minor if you don't switch to using the '628's built-in UART. I don't have one of those parts at the moment, though.

Wykat,

I suggest starting a new thread...

-Jon

mitko

October 13th, 2002, 03:55 PM

I have a question for Jon. Does your UIRT PlugIn support the old UIR device? If yse what do I have to do to make it work? I need a second plugin working on WinXP for my second UIR. The Universal Serial .... for the moment has a bug and crashes while closing.

Kevdog

October 13th, 2002, 03:55 PM

Dear Jon_Rhees:

From what I gather about your modified design, it is very similar to the 16F84 schematics: http://www.geocities.com/SiliconValley/Sector/3863/uir/Images/uir1684.gif

I too, do not need the capability to perform in circuit programming of the PIC, and it would seem to be easier to implement a switch if the circuit were truly referenced from ground.

Before I build this modified circuit, I wonder if you could provide me with a few clarifications however:

1)RTS and DTR are tied together as you described and run to MCLR, VDD, and VS on the IR receiver
2) GND is carried directly to PIN 5 (GND on the PIC), GND on the IR receiver, and the IR emmitting diodes
3)TXD is carried through a resistor directly to RB6.
4) RB5 and RB4 are tied together go to the IR emmitting diodes through 100 ohm resistor as in the original description.
5)Out on the IR receiver is carried to RB3.
6)RxD is carried directly to RB7????

I gather that the other capacitors and zeners are arranged similarly to that originally described in the UIR.

Thanks for the input and the discussion

Kevdog

October 13th, 2002, 03:55 PM

Jon

Thanks for the reply. As I stated earlier,this schematic was derived directly from the UIR site. It is the schematic I used to build my original UIR. I mention this schematic because for me, it would personally be easier to wire in the two extra IR LED's without having to construct a new PCB, and purchase additional parts.

Ideally it would be great the alter the PIC code to support the as much as the original pin configurations as seen in the 16F84 UIR schematic.

With the 16F84 data sheets from Microchip sitting in front of me, but inexperienced in PIC progrmmaing, I am not sure why this design could not implement the further design changes as discussed above. I will leave you to ponder that as you seem to be far more experienced than I.

I would support you on making the changes to the .asm code, I hope others would do the same

Kevdog

October 13th, 2002, 03:55 PM

Is it possible to change the modulator frequency of the PIC through software rather than hardware, and is it possible for this circuit, with possible slight modifications to drive a RF transmitter, in addition to an IR transmitter

Thanks

Kevdog

October 13th, 2002, 03:55 PM

Wanted to know genexia if you were still working on your switch idea. Ive got a few questions regarding the switch, the use of EPROM memory, and the likes

tslope

October 13th, 2002, 03:55 PM

Ok, I am getting ready to make myself a UIRT but I am having problems locating a TSOP1738 or an equivalent. Newark has none in stock and has a message "lead time 90 days" for the part, which does not sound good.

October 13th, 2002, 03:55 PM

Hi All,
I'm running into problems trying to program the pic. on win98 new uirprog gives "err writing config word" and the old uirprog gives "err writing pic data". I have tried diff hex files with same result. Any suggestions/help is appriciated.....

Regards,
-bk

Danijel_Pticar

October 13th, 2002, 03:55 PM

Hi.

I have now converted 4mhz code to 10mhz+some small fixes in code. I menaged somehow to code girder plugin, its beta*2 writen using borland vlc so its little big.. Also I have fixed UIRT programmer so its should programm all PICs now on all OSes.

It would be great to someone test Transsmit. I have tested it on TV and video only.
Also if someone will test on RC5 remotes it must grab both codes, and transmith both codes.

files are located at http://student.math.hr/~dpticar/uirt.htm

bye ...

Danijel_Pticar

October 13th, 2002, 03:55 PM

Hi.

I see that peoples are confuzed with 2 uir firmwares and 2 plugins. I use in my firmware and plug extension 'dp' like 10mhzdp.hex.

Ill now try explain problem with rc5 remotes, or we can say devices that uses rc5.

rc5 remotes have 2 signals for one buttton. When you pres first time it sends button_CODE1, and second time you pres it send buuton_CODE2. This two codes are different in two first bits only. So your code looks like 01xxx, and another time 10xxx. Lets call this two bits sync bits. Now when you turn on your TV, TV waits for remote code but that code must have sync 10, not 01. After you pres any button and tv receive that code it waits for another code wich starts with sync 01, and next time with 10 etc.. (if it receive code with wrong sync TV will not react to code)

So you practicly have to send both codes with sync 10, and 01. This could be also problem because if your tv wias for 10, and you send 10, and that 01, so if that function is multifunction (like tone controls, bass,trebla fad etc..) it can skip desired function.
Also I noticed that my TV have problems with RC5, and problem is not bad learning or carrier. I think its waiwlength of IR diodes. Ill look around rc5 in next couple of days, try to find problems.
Also I have 3 RC5 remotes, and all of them have first 8 bits same (all different devices). So if all rc5 have first 8 bits same it can be detected that its rc5, of course if we asume that there is no space or puls coded remotes with same first 8 bits.

Thats all I know about RC5.

Also I also thing that having incompatible firmwares (protocol of UIRT) is confusing for peoples, and thay have to use plugin that is only for that firmware.
Problem is in 115200bps that Ruds uirt use in T mode. That speed can not be acomplished well in 4mhz pics. On some computers will work on some not.
Only problem that I see on 4mhz is that carrier cant be accurate like in 10mhz.

OK that THE END for now :smile:

bye sorry for loong post ...

Danijel_Pticar

October 13th, 2002, 03:55 PM

Hi.

I have tried u24.hex (on 10mhz) pic, and learning/transmiting wont work.
This is how raw data looks (32bit remote space coding).
71 32 14 10 22 10 14 10 ..... <- from girder.
142 68 10 7 10 24 10 7 ..... <- real remote .
and lenght is onlu 37 pulses+spaces, and it should be 67.

RC5
9 4 13 4 13 ..... <- girder
15 12 28 12 15 ..... <- real remote
lenght is good here

u24-04mhz
RC5 is fine (it wont work on my TV but its probably problem I mentioned in previus post
)
Also I tried 4 types of different space coded remotes, and learning havent worked at all..

bye

Danijel_Pticar

October 13th, 2002, 03:55 PM

Hi.
Jon : I have 2 UIRTs one on com1, other on com2. First uirt Im using to receive every puls and space length. I use for that my prg RCV11 (Remote code view) wich shows me IR signal exactly how it looks, very handy for debuging. Onother one Im using with Girder or some other program to send learned code, and Im comparing that two signals.

71 32 14 10 22 10 14 10 .....
means that first pulse was 71*64 us long, space was 32*64 us long, etc ... Thats what I get when Im learning using your hex+plug.

And when using original remote I get big differenc + there is not enough pulses+spaces on some remotes.

Looks like wrong setuped prescaler, but dunno why wont learn 32bit remotes on4mhz, and why is code to short on 10mhz ..

genixia : CTS is used during programing to verify writen data ..

btw : I have uploaded to my page new girder plugin ver 1.2 and 4mhz version 1.2 hex file.
RC5 are repeated like original but probably wont work, I think I have clue what is it, and Ill try to fix that..
Also I have aded ability to girder plug to popup Form from which can be selected one of 4 codes received when learning new code.
Thats very useful when remote control sends precode,postcode or both, so you can select right code (Grunding, Finlux are that kinda remotes).

bye

Danijel_Pticar

October 13th, 2002, 03:55 PM

Hi

Jon:
Here are Timings for 32 bit space coded remote.

141 69 9 8 9 25 9 8 9 8 10 24 9 8 10 24 9 25 9 25 9 7 9 25 9 25 9 8 9 25 9 25 9 8 9 25 9 25 9 7 9 25 9 25 9 8 9 7 9 25 9 7 9 8 9 25 9 8 9 8 9 25 9 25 9 8 9

multiply with 64 to get us.

my E-mail is danijel.pticar@zg.hinet.hr .
But maby you could open www so other ppls can test you code.

ACClark :
Hmm.
Well Its true that I have changet way I init comPort (but to better).
Well Im not some good electrican, but I think that that 100uF cond. wont let your uirt to reset fast, becuse its supplying your uirt for some time after comport was closed.
Also have you checked did you selected good com port in Girder under settings..
Also what other tools from my page are working. Does Transmiting when using uir-test is working ...
Im using RTS to reset uir, and you dont have that ..

Can anyone confirm that my plug is working anywhere, or its only working for me :smile:

bye

Danijel_Pticar

October 13th, 2002, 03:55 PM

Jon :
I forgot ...
Yeah progress bar wont advance on 32bit code ...

Danijel_Pticar

October 13th, 2002, 03:55 PM

Hi.
Jon:
I tried new code & plug (only 10mhz, 4mhz ill tomorow or better say today when I wake up). When Im using 32bit remote progres bar wont advance when Learning or when I press that small button with point.

RC5 - work but now are pulses+spaces to loong.
----
15 13 28 13 14 13 14 13 14 13 14 13 14 13 14 13 14 26 28 13 14 13 14<- real remote RC5 button 8

38 27 58 27 42 27 42 27 42 27 42 27 42 27 42 27 42 62 42 27 42 27 42 <- your
---
00 5E 4A 5B 4A B4 4A 5B 4A 5B 4A 5B 4A 5B 4A 5B 4A 5B A3 B4 4A 5B 4A 5B FF (* lotsa times)
and
00 61 47 B7 47 5F 47 5F 47 5F 47 5D 48 5C 4A 5F 47 5F 9F B7 47 5F 47 5C FF (*2)

comes from small button.

Can you confirm that my new plug+hex works.
I have changed lotsa stuff when I moved from win98se to XP.

Clark : Both DTR&RTS are set when starting UIRT. Try replacing that 100uF with 3uF.
Sorry I cant help you.
Why you dont build uirt original, you can make that on universal pcb...

bye

Danijel_Pticar

October 13th, 2002, 03:55 PM

Jon.
It work now.
RC5 are OK (but rc5 logic is bad, it must be able to learn code with another sync).

32bit remote is ok, onlu header is bad
142 68 10 7 10 24 10...<- real remote
40 66 11 6 11 23 11... <- your

There are buttons that sends stop code, and some not I tried both, and it didnt work, and now works ..
Here are specifications of my remote 32bit ..

Name : Onkyo
Code length: 32 bits
Carrier: 39.2kHz

Header : 16T(puls) + 8T(space)
1 is coded : T(puls) + 3T(space)
0 is coded : T(puls) + T(space)
Last (pulse) is terminator puls.
Stop code is coded : 16T(p)+4T(s)+T(p)

T=550uS
95000us between the headers of the codes
(Pineer have very similar structure)

In my prg I have test to ignore remotes that have length less then 4.(this kills stop codes)

bye

Danijel_Pticar

October 13th, 2002, 03:55 PM

Jon.

Heres table of remotes
Brand Length Type HeadP HeadS 1Pulse 1Space 0Pulse 0Space Space
Akai 32 Space 8800 2200 550 1650 550 550 11000
Akai stop 0 None 8800 4400 550 0 0 0 83000
Canon 32 Space 8800 4400 550 1650 550 550 40000
Denon 15 Space 0 0 275 1900 275 775 43000
Finlux pre 10/16 Shift 500 5200 500(1) 530 500 530(1) 105000
Finlux 10/16 Shift 500 5200 500(1) 530 500 530(1) 105000
Finlux post 10/16 Shift 500 5200 500(1) 530 500 530(1) 105000
Funai 24 Space 3200 3200 800 2400 800 800 30600
Goldstar 32 Space 8800 2200 550 1650 550 550 11000
Goldstar stop 0 None 8800 4400 550 0 0 0 83000
Grundig pre 10 Shift 500 2600 500(1) 550 500 550(1) 18000
Grundig 10 Shift 500 2600 500(1) 550 500 550(1) 120000
Grundig post 10 Shift 500 2600 500(1) 550 500 550(1) 120000
Hitachi 32 Space 8800 2200 550 1650 550 550 11000
Hitachi stop 0 None 8800 4400 550 0 0 0 83000
JVC 16 Space 2080 4160 520 1560 520 520 20500
Kenwood 32 Space 8800 2200 550 1650 550 550 11000
Kenwood stop 0 None 8800 4400 550 0 0 0 83000
Mark sample 17 Space 8400 4200 500 1500 500 500 4000
Mark part 1 8 Space 8400 4200 500 1500 500 500 0
Mark part 2 8 Space ---- ---- 500 1500 500 500 10000
Mitsubishi 16 Space ---- ---- 300 1950 300 880 24300
Nec 32 Space 8800 2200 550 1650 550 550 11000
Nec stop 0 None 8800 4400 550 0 0 0 83000
Onkyo 32 Space 8800 2200 550 1650 550 550 11000
Onkyo stop 0 None 8800 4400 550 0 0 0 83000
Orion 33 Space 9000 4450 550 1650 550 550 34200
Old Panasonic 22 Space 3650 2750 910 2750 910 910 41130
Old Pana. US 22 Space 3375 2530 844 2530 844 844 37980
Panasonic 48 Space 4000 1600 400 1200 400 400 76000
Philips 14 Shift ---- ---- 889 889 889 889 24889
Pioneer 32 Space 8000 4000 500 1500 500 500 62000
Salora 12 Space 50 550 0 375 0 190 238000
Sanyo 32 Space 7850 4200 525 1575 525 525 23000
Schneider 12 Space ---- ---- 1250 450 450 1250 34200
Sharp 17 Space ---- ---- 275 1900 275 775 43000
Sony 15 Pulse 2200 550 1100 550 550 550 23000
TEAC 32 Space 8800 2200 550 1650 550 550 11000
TEAC stop 0 None 8800 4400 550 0 0 0 83000
Old Technics 22 Space 3650 2750 910 2750 910 910 41130
Old Techn. US 22 Space 3375 2530 844 2530 844 844 37980
Technics 48 Space 4000 1600 400 1200 400 400 76000
Yamaha 32 Space 8800 2200 550 1650 550 550 11000
Yamaha stop 0 None 8800 4400 550 0 0 0 83000

Danijel_Pticar

October 13th, 2002, 03:55 PM

Jon.

I use resolution of 64uS(4mhz), and 51.2uS(10 Mhz), I think thats enough, because remotes dont have very good timings , for example my header is one time 8800, and another 9200, similar thing is with rc5 remotes.
As you see from table lotsa remotes have long header ..
Your remote have puls 150uS.. Thats very short. (your remote is practicly a modem :smile: )
Have you tried to test that remote on my app RCV11. It sends at 57600, and if your remote have that short pulses app will not work ok (115200 is needed for that short pulses)..

Danijel_Pticar

October 13th, 2002, 03:55 PM

Hi all.

I have fixed bug in girder plugin version 1.2. Bug was that plugin was fixed to COM2 when using Action Plugin. Thats fixed now.

Also I have uploaded new uirt-test app(manual adjusment of learned code and carrier).

location same :
http://student.math.hr/~dpticar/uirt.htm

Concurently I dont have idea what more to add. Any sugestions ??

bye

Danijel_Pticar

October 13th, 2002, 03:55 PM

genixia,

CTS is input.
DTR is output and its used to programm pic.
On your schematic you dont have any output(from pc to pic) so in circut programing is not possible.

bye

Danijel_Pticar

October 13th, 2002, 03:55 PM

Jon.

Hehe, well you havent readed my post few days ago about rc5.
Ill now say again shortest I can all I know about rc5 remote, and rc5 TV(for example).
When you turn on TV (plug it to power switch), it waits for for TOGLE bit 1 (+rest of code). TV will not turn if receives wrong Toggle bit.
When it receive Togle bit 1 it turns on, and waits for command with TOGLE bit 0 (on all other commands with TOGLE 1 will not respond), and soo on (1,0,1,0,1,....).

Yeah if you point remote to TV and it respod to command, and second time you point it away, and 3rd time you point it to TV it will not react to command. (Thats 100%, but Im not shure that all TV are stupid like mine and my friend (Philips, Samsung), maby some TV will work on both TOGLE bits).
Also there is aditional tricks that complicates RC5 devices to react on learned code, I cant talk what is it coz I dont know, I have to analyse better RC5, butt Im concurently little out of time to play with RC5. Maby you can try to figure it out.

Of course remote sends one time you press (or hold) button TOGLE 1, after you release and press again it sends TOGLE 0 (or reverse), ......
----
I have tried 4mhz and everything works.
10mhz Girder frezzes (maby even crashes on Win98, dunno have xp)

bye