Pocket pc TV remote control (source code)

 

Pocket pc TV remote control (source code)

Author: Nick Deacon Source: codeproject

Download> Introduction Have you ever wanted to be able to control your TV, hi-fi, or video using the IR port on your Pocket PC? Here's how to do it. Background I recently lost the TV remote for my old Sony TV. in itself that was no problem, as I bought a replacement remote which did the job. however, when the TV lost its color setting, I had a problem as it cocould only show pictures in black and white, and the replacement remote didn't have the buttons for Color adjustment. I decided to write a program on my old Jornada 525 Pocket PC to send the correct codes to the TV using the IR port. There appears to be three main protocols for sending IR codes to devices. sony uses the 'pulse coded' method which entails sending a steam of Data ining header bits, '1' bits and '0' bits separated by spaces. these bits modulate a carrier of 40 kHz, and are of different lengths, 2200 us for the header, 110 us for a 1 bit and 550 us for a 0 bit. the spaces are 550 us of silence. most Sony equipment uses 12 bits of data, which is separated into 6 bits of address (the device type) and 6 bits of command. so the data looks like this: hxxxxxxyyyyyy where H is the header bit, xxxxxx is the 6 bits of the command (MSB first) and yyyyyy is the 6 bits of address. I won't go into any further details on this, as there are using sources on the Internet that describe the protocol and list the codes for the different devices. some newer Sony equipment use 19 bit codes, and I believe that other manufacturers use the same format that I have described. it shoshould also be possible to write similar classes for devices that use 'space coded' or 'shift coded' protocols. I have written a class calledCIrPulse Using embedded C ++, which encapsulates the functionality to control Sony and compatible devices from a Jornada 525 PC running Windows CE 3.0. it shoshould work with other devices and operating systems, but you will need to try it! Using the code TheCIrPulseClass exposes a number of functions which makes sending IR codes as easy as possible. On declaringCIrPulseClass you shoshould callFindIrPort()Once. this returns a uint which represents the port number for the IrDA port, which it gets by looking in the registry. this port number is used in all subsequent callto open the IrDA port for serial comms. UINT CIrPulse::FindIrPort(){ // Look into the registry for the IR port number HKEY hKey = NULL; if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, _T("Comm//IrDA"), 0, 0, &hKey) == ERROR_SUCCESS) { DWORD dwType = 0; DWORD dwData = 0; DWORD dwSize = sizeof(dwData); if (RegQueryValueEx(hKey, _T("Port"), NULL, &dwType, (LPBYTE) &dwData, &dwSize) == ERROR_SUCCESS) { if (dwType == REG_DWORD && dwSize == sizeof(dwData)) { RegCloseKey(hKey); return (UINT) dwData; } } RegCloseKey(hKey); } return 0;} Having got the port number, you can callOpen(UINT)Function, passing the port number already ed from the callFindIrPort(). This opens the port and sets the serial parameters, returning true if successful. the port is set to 115200 Baud, 8 data bits, 2 Stop bits and even parity. A discussion of how the carrier is produced, and why I have used these settings appears later in the article. BOOL CIrPulse::Open(UINT uiPort){ ASSERT(uiPort > 0 && uiPort <= 255); Close(); // Open the IRDA port CString strPort; strPort.Format(_T("COM%d:"), uiPort); m_irPort = CreateFile((LPCTSTR) strPort, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (m_irPort == INVALID_HANDLE_VALUE) { return FALSE; } // Set the size of input and output buffers VERIFY(SetupComm(m_irPort, 2048, 2048)); // clear the read and write buffers VERIFY(PurgeComm(m_irPort, PURGE_TXABORT | PURGE_RXABORT | PURGE_TXCLEAR | PURGE_RXCLEAR)); // Reinitializes all IRDA port settings DCB dcb; dcb.DCBlength = sizeof(DCB); VERIFY(GetCommState(m_irPort, &dcb)); dcb.BaudRate = CBR_115200; dcb.fBinary = TRUE; dcb.fParity = TRUE; dcb.fOutxCtsFlow = FALSE; dcb.fOutxDsrFlow = FALSE; dcb.fDtrControl = DTR_CONTROL_DISABLE; dcb.fDsrSensitivity = FALSE; dcb.fTXContinueOnXoff = FALSE; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fErrorChar = FALSE; dcb.fNull = FALSE; dcb.fRtsControl = RTS_CONTROL_DISABLE; dcb.fAbortOnError = FALSE; dcb.ByteSize = 8; dcb.Parity = EVENPARITY; dcb.StopBits = TWOSTOPBITS; VERIFY(SetCommState(m_irPort, &dcb)); // Set the timeouts for all read and write operations COMMTIMEOUTS timeouts; VERIFY(GetCommTimeouts(m_irPort, &timeouts)); timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; VERIFY(SetCommTimeouts(m_irPort, &timeouts)); DWORD dwEvent=EV_TXEMPTY; SetCommMask(m_irPort,dwEvent); return TRUE;} Call the FunctionSetCodeSize(DWORD)To set the number of bits to transmit (eg 12 ). this can be done at any time, and only needs to be done once. it remains in effect until a subsequent call to change it. Finally callSendCode(long)Passing the actual code to send. BOOL CIrPulse::SendCode(DWORD lValue){DWORD dwCount;int i=0;ASSERT(iDataLength>0);//purge the transmit buffer VERIFY(PurgeComm(m_irPort, PURGE_TXABORT | PURGE_RXABORT | PURGE_TXCLEAR | PURGE_RXCLEAR));// send the code 6 times for each button pressfor(int x=0;x<6;x++) { MakeStream(lValue); //send the code dwCount=GetTickCount(); while(GetTickCount() 26 ) // Delay for 26 MS I ++; } Return true; } Note that this function callanother FunctionMakeStream(long)6 times, pausing for 26 Ms between each call. I have found that the code has to be sent a number of times for the processing device to respond, presumably to prevent spurious activation. the delay of 26 Ms is necessary for the processing device to register the code, before the next one appears. The FunctionMakeStream(long)Writes the stream of bytes to the irport, and ensures that the correct length of packet is sent depending on whether a start bit, '1' bit or '0' bit is to be sent. the buffer containing the bytes of data (0xdb) is in the form of a bytearray. The FunctionClose()Naturally enough closes the irport after use. The function works fine on my Jornada, but see the discussion below to see what changes you might have to make. BOOL CIrPulse::MakeStream(DWORD lValue) { DWORD dwStreamLength; //make the start pulse dwStreamLength=iHPulse/charWidth; ASSERT(Write((const char *)bPulseStream.GetData(), dwStreamLength)==dwStreamLength); // ******************************************** // ***** The Delay before the next pulse goes here // ******************************************** //loop through the bits in the Code sending the pulse for(int i=0;i if(lValue & 1) { //make the 1 pulse dwStreamLength=i1Pulse/charWidth; ASSERT(Write((const char *)bPulseStream.GetData(), dwStreamLength)==dwStreamLength); // ******************************************** // ***** The Delay before the next pulse goes here // ******************************************** } else { //make the 0 pulse dwStreamLength=i0Pulse/charWidth; ASSERT(Write((const char *)bPulseStream.GetData(), dwStreamLength)==dwStreamLength); // ******************************************** // ***** The Delay before the next pulse goes here // ******************************************** } lValue >>= 1; } return TRUE;} I have included a simple application, which usesCIrPulseTo create a remote control for a Sony TV. This has the basic functions of channel selection, volume control and on/off. Points of interest BecauseCIrPort Class uses a serial comms interface to the IR port, a 40 kHz carrier has to be generated by sending appropriate characters out of the serial port. fortunately if we send the character 0xdb at 115200 baud with 8 data bits, 2 Stop bits and even parity, this has the effect of producing a 38.4 kHz carrier which is close enough. all my Sony equipment accept this without problems. The biggest problem is how to achieve the periods of silence which separate each pulse. it is not possible to produce pure silence out of the serial port, as even if you send a 0x0 character, you still get pulses on the IR due to start and stop bits. I experimented with sending different characters on the assumption that if you can send a carrier at frequencies other than 40 kHz, this might fool the device into accepting this as a silence. this has the advantage in that you can produce one bytearray containing the data for the entire code, ensuring that the timing is accurate. the results however were not consistent, and I rejected this method in favor of pausing between sending the groups of 0xdb characters out of the serial port. because the delay needed is in the order of 550 us, there is no way (that I found) of consistently achieving this delay which is independent of processor speed. on my Jornada I didn't need to create a delay at all, as each call toWriteFunction seemed to take the correct amount of time. anyway, I am afraid to say that you may have to fiddle about to create a delay that works with your Pocket PC. if any one can work out a fool-proof way of achieving the correct delay for any device, please let me know!