Trying to find the means to control my Philips DVD Recorder with RS232. Am I in the right place? If not I apologize and would apprceiate someone pointing me to the right group.
The DVD Recorder has an RCA style output for wired remote control. It uses Philips RC6 protocol. I'd like a cable that connects this to to my RS232 port. Most likely it will need a microcontroller inline to convert commands.
Any help in this area would be greatly appreciated.
Thanks
Last time I looked, Philips were not open about the RC6 protocol. They don't want a repeat of RC5, were other companies did not conform to the spec or added their own button codes.
"kryten_droid" wrote in news:zMemb.780$ snipped-for-privacy@newsfep1-gui.server.ntli.net:
That's why I can't find squat about it. How about Pioneer's protocol. Their new DVD recorder has a wired RC jack as well.
Wouldn't the wired protocol be the same as the IR remote uses? There should be software for PDAs and such to sniff out IR codes. (Although I recall some stupid patent fight .. as usual.) Once Chris has those, it would be easier to figure out if a normal serial port could generate them. If not, stick an itty bitty controller inbetween.
-- Ron Sharp.
Unlikely.
IR control signals don't have the same timing as an RS232 port uses.
There are systems where an IR sensor in a dongle just sends the signal up a cable. This has the advantage that it is cheap and there are no protocol problems. Some Arcam kit has sockets for such cable inputs (I think the multi-room module for example).
An alternative approach I have seen used with PCs is to have a micro in the dongle that senses a particular protocol's messages then repackages them in RS232 format and sends them to the PC. I had this system with a PCTV card I once bought.
I believe Meridian had a system where the PC used an RS232 to RS485 adapter and the Meridian hi-fi modules talked to the RS485 bus.
"kryten_droid" wrote in news:ebkmb.956$ snipped-for-privacy@newsfep3-gui.server.ntli.net:
That's it. Avit Research in the UK makes such a cable. They put a micro directly in the RS232 plug. Check it out
Unfortunately theirs is for Sony Control L. I'm looking for Philips and/or Pioneer control.
I don't know the first thing about RS-232 or Pioneer protocol and I'm just getting into the world of microcontrollers so I'm really floundering here. I do know it must not be all that complicated but I just don't have the experience.
Which micro to use to do this sort of thing? What are the protocols? If I'm armed with the info I need, I can at least hire someone to help if I can't figure it out myself.
Any more suggestions?
Thanks for all your help so far. I'm learning everyday.
These pages contain good info about IR control systems
RS232 serial communication is pretty common knowledge now, but way back in the 80s when it was not, people wrote a lot about it. Google for the text of "hacker's handbook" "Hugo Cornwall". Mostly out of date, but there is plenty about serial communication signals.
IR protocols are in two camps: NEC and variants have a header (long pulse on then off to get the receiving micros attention) then bits are coded by the time between the leading edge of IR pulses. The less common RC5 uses phase-coding.
A small 8-pin micro might do - e.g. the PIC. You will have to bit-bang the RS232 port.
I prefer to use the small AVR chips which have a hardware UART.
RC6 is probably an extension of RC5. Maybe with 6 system bits instead of 5, and with button codes tightly controlled by Philips.
What is your application?
If your having so much difficulty at this level, how much else is there to tackle?
K.
RC6 uses the same low-level manchester type coding as RC5, but has more bits, to cope with more devices and functions, and runs at a slightly higher bit rate.
The RC6 spec is rather hard to find, but there is plenty of info on RC5, and once you understand how RC5 works, RC6 can easily be deduced by looking at some sample codes.
bits, to cope with more
That confirms my suspicions.
I know. So hard, I can't find it! Annoyingly, it is also the name of a cipher algorithm.
I don't have a scope to observe such signals. This prevents me from writing RC6 compatible code.
These articles say Philips is to licence RC6 to Microsoft
According to Daisy Laser, these are valid RC6 codes
"kryten_droid" wrote in news:wbumb.2592$ snipped-for-privacy@newsfep2-win.server.ntli.net:
The application is to control two of the recorders simulataeously from the same PC. Record/Play/Pause/Frame Step/etc.
Good question. I am brand new to embedded microprocessors. I have a sincere interest in getting to know what I'm doing...I have lot's of project ideas. It just so happens I really need this one and I figure it should be about as simple as it gets so it's a good one to start with.
Transmitting codes is a lot easier than receiving them.
Though note that the micro will need to know which cable to drive.
Yes, I agree.
"kryten_droid" schreef in bericht news:79xmb.2990$ snipped-for-privacy@newsfep2-win.server.ntli.net...
RC5,
To get the spec Philips wants you to sign a non-disclosure agreement, so normally you shouldn't find it at all on the 'Net
Not necessarily. You don't want to know about all the stuff MS licensed and never actually used. Main reasons to license a technology:
- you need it. Now.
- you may want to use it in the future.
- you want to know what your competitor is up to.
-- Steven
The cads! :-)
If it is as simple as an RC5 modification, then it should be easy for people (with scopes) to get the info and put it on the web. If I had a scope and an RC6 handset I would have a go myself.
Why on earth..... what could Philips possibly lose by disclosing this info - it's so widely used that anyone could figure it out in a few minutes.... Lawyers have gone mad!
No way. You can't go somewhere you already are... ;->
-- Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
I think the authors of RC6 saw that manufacturers had strayed from the RC5 specs regarding button codes. So this time they are trying to make sure that does not happen by insisting you check with them first before they let you say it is RC6 compatible. The spec allows manufacturers to have their own arbitrary codes if they really have to, but they have to apply for their own 'code page' to avoid overlap with anyone else's code page. Hence lawyers to deter deviations.
You can find some RC6 infomration here. See page 25.
regards, Johnny.
I think this approach actually makes matters worse. If they had published everything with clearly defined button codes, and a system of allocating device codes, people would generally follow it.
As it is, people will just reverse-engineer it and do their own thing.
Well, they have assigned a reasonably common set, but can't guarantee to be perfect.
e.g. many buttons toggle states: the standby button = on off. Fine if the human user is there, but an automated home entertainment system cannot tell so it cannot do tasks like "switch off everything at a preset time". Your beside radio might well be 'off' but you might also have woken early and already switched it on - in which case the on/off toggle code will switch it off. So it is good to allow codes for such unforeseen requirements.
I've had a look at the pronto.pdf file and it all looks a lot clearer to me now.
"RC6" is the basic simplest form:
Header::Toggles::System(8-bit)::Command(8-bit) This presumably uses the official standard meanings for systems and commands.
"RC6A" has a slightly different header, and inserts an extra 8 or 16 bits after the Toggles. The earliest bit dictates whether it is 8 or 16. This allows 128 plus 32678 manufacturer-specific codes. Each officially-numbered manufacturer can then interpret the system and command codes as they please.
They cannot do that and call it RC6 or RC6A.
Also, they risk interference from legitimately coded equipment.
So it is in their own interests to conform, lest their troublesome equipment gets mentioned in HiFi News etc.
The main point is that most people can share a common set of codings to allow manufacturer's handsets to be compatible with each other's equipment.
The second point is that if a manufacturer invents something completely new that does not have an existing system/command code set, they can apply to have it registered as an official RC6 code set.
If their new gadget doesn't look like it is going to become a common product worthy of the limited official RC6 system codes, they can be assigned an 8 or 16-bit manufacturer code and do their own thing with their system/command coding. The RC6 / RC6A authorities can then wash their hands of that. Even if the manufacturer makes a complete pigs ear, they've only made a mess for themselves. Other manufacturer's equipment will either think "Its not RC6" or "Its RC6A but not my manufacturer" and ignore it.
This is all only going to work if there is one organisation authority to administer the codings, and Philips have the right to do so.
That would give them good reason to, say, register a trademark and request people to go through a validation process before they get a licence to use that trademark, like, e.g., Sun does it with Java, or what the USB people do.
This is *not* a sane reason for requiring people to sign an NDA just to get access to the specs, though.
-- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.