Universal InfraRed Transceiver support

[oe1k]

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

<font size=-1>[ This Message was edited by: oe1k on 2001-07-20 23:23 ]</font>

[Ron]

I'm not aware anyone is Working on it. But Ruud (the creator) has expressed his cooperation in making a driver! So as soon as i can get my hand on one of these, or if Ruud gets the time there'll be a driver. Don't hold your breath tho.

[Mark F]

URL to the hardware page, please. :smile: (I'm not sure which one you are talking about)

Thanks.

[jediperry]

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.

[Mark F]

This should use the UIR plugin(s) for receive until a specific plugin can be written for the transmit portion. I don't have this hardware and don't have the equipment nor experience to build one. :sad:

It would be hard to write/debug software without the device. Sorry.

EDIT: I should have re-read the orginal post. I'd love to have one of these made for me. Let me know when you get one done and we can work out the $$, shipping, et al.

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. :smile:

_________________
Mark F

<font size=-1>[ This Message was edited by: Mark F on 2001-07-29 14:12 ]</font>

[oe1k]

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...

[Mark F]

AVS Forum: AV Science Forum - In my opinion, one of the best places to talk and learn about Home Theater (HT) on the internet. They have a dedicated place for discussing the use of PCs (HTPCs) in a HT environment that is second to none.

This (http://www.avsforum.com/ubbcgi/Ultimate.cgi) is where I learned about Girder.

[oe1k]

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?

[Mark F]

If they will be the same, I just want the one. As I told Craig, I'd be happy to pay parts, S&H and $$ for labor/effort. I know you guys are doing this because it is fun to tinker but I don't want to take advantage of anyone. :smile:

A question I've had about these designs: How hard would it be to modify this design to use an external IR sensor and transmitter block?

Things like these:
http://smarthome.com/8191.html
http://smarthome.com/8120.html

Would it then require an external power supply? Thanks.

[Ruud]

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

[Ron]

There are lots of example plugins available and there is also a API documentation (not written by me :grin: thus good quality )

Let me know if I can help

[Mark F]

Ruud,

Welcome to the Girder board! When I receive one of these IR transceivers, I'll write a Girder plugin for it. I'd like to re-use/re-package the code in your .dll, if that is OK with you. I'll be sure to mention the origins of the code in the readme file.

[Ruud]

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]

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

[Mark F]

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.

[Wykat]

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

[Mark F]

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:

[jcase]

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

[oe1k]

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.

[jcase]

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

thanks

[oe1k]

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).

[jcase]

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]

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]

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

[oe1k]

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).

[jcase]

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.

[oe1k]

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]

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!

[jcase]

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.

[oe1k]

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:

[jcase]

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:

[Mark F]

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

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

[Mark F]

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

<font size=-1>[ This Message was edited by: Mark F on 2001-08-29 20:28 ]</font>

[DP]

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

[Ron]

On 2001-08-29 06:24, jcase wrote:
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


Maybe the UIRT didn't 'see' that signal correctly, where you close to the receiver ?
No fluorencent lights around.. stuff like that.

[jcase]

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

[Mark F]

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.

[oe1k]

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?

[DP]

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

[jcase]

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

thanks

[oe1k]

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

<font size=-1>[ This Message was edited by: oe1k on 2001-09-06 18:09 ]</font>

[jcase]

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:

[Mark F]

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.

[Ingo]

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

[oe1k]

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!

[Mark F]

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.

[Dionysus]

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?

<font size=-1>[ This Message was edited by: Dionysus on 2001-09-17 10:11 ]</font>

[Wykat]

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.

[Mark F]

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.

[jcase]

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

thanks

[Mark F]

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:

[jon_rhees]

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

[Ron]

Wow Jon, that sounds great! I can host the modified plugin (and pic code if needed) on the download page for you if you like.

-Ron

[ACClarke]

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

[Mark F]

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?

[Wykat]

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

rgrds,
Wykat

[jon_rhees]

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

[Wykat]

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:

[Mark F]

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:

[jon_rhees]

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

[Mark F]

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

[Ron]

The device code has been handed out, we are now waiting in deep suspense for the release :grin:

[Ron]

The UIRT stuff has been uploaded thank to Jon for the work!

[ACClarke]

thanks a lot !!

[ACClarke]

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 !!

[Wykat]

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]

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

[Wykat]

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]

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

[jon_rhees]

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

[Wykat]

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

[jon_rhees]

Wykat,

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

-Jon

[genixia]

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?

[jediperry]

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

[Ingo]

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

[Wykat]

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.

[genixia]

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.


<font size=-1>[ This Message was edited by: genixia on 2001-10-17 18:13 ]</font>

[genixia]

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.

<font size=-1>[ This Message was edited by: genixia on 2001-10-17 18:20 ]</font>

[genixia]

jon_rhees,

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

[Ingo]

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]

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)

[jon_rhees]

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

[genixia]

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?

[jon_rhees]

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

[Ingo]

jon,

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

[genixia]

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.

[Wykat]

@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

[Ingo]

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.

[jon_rhees]

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

[jediperry]

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

[genixia]

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.

[tslope]

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.

[Robin]

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 ?

[genixia]

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]

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??

[Ingo]

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

<font size=-1>[ This Message was edited by: ingo on 2001-10-18 18:45 ]</font>

[genixia]

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.

<font size=-1>[ This Message was edited by: genixia on 2001-10-18 19:56 ]</font>

[Robin]

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 !

[jediperry]

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

[genixia]

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?

[Robin]

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 ?

[jediperry]

... 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: )


<font size=-1>[ This Message was edited by: jediperry on 2001-10-18 23:00 ]</font>

[genixia]

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:

<font size=-1>[ This Message was edited by: genixia on 2001-10-18 23:14 ]</font>

[genixia]

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...

[jon_rhees]

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

[genixia]

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!

[Robin]

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 !

[genixia]

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?

[jon_rhees]

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.

[genixia]

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]

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

[Kevdog]

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

[Ron]

Guys, feel free to start a new thread for different questions :smile: Is there a need for a separate forum for UIRT ? I'd be happy to host it here.

-Ron

[jon_rhees]

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

[Kevdog]

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

[genixia]

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.

<font size=-1>[ This Message was edited by: genixia on 2001-10-22 18:33 ]</font>

[jon_rhees]

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

[genixia]

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?

[Ingo]

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)

[jon_rhees]

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

[genixia]

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.



<font size=-1>[ This Message was edited by: genixia on 2001-10-23 00:50 ]</font>

[jon_rhees]

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

[genixia]

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:

[bk]

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

[genixia]

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.

[jon_rhees]

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

[jediperry]

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

[jon_rhees]

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

[genixia]

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.

[Kevdog]

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

[genixia]

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.

[Danijel_Pticar]

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 ...

[ACClarke]

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

[jon_rhees]

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

[ACClarke]

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

[jon_rhees]

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

[ACClarke]

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.

[jon_rhees]

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

[ACClarke]

1.yes

2.i use U24mhz4.hex and only this one

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

[jon_rhees]

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

[genixia]

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.

[ACClarke]

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

[jon_rhees]

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]

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

[ACClarke]

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

[Danijel_Pticar]

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]

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

[jon_rhees]

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

[genixia]

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)

[Danijel_Pticar]

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

[ACClarke]

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]

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

[jon_rhees]

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]

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

[Danijel_Pticar]

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]

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

[genixia]

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.

[ACClarke]

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.

[jon_rhees]

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