Guest candyfeng Posted March 26, 2005 Report Share Posted March 26, 2005 I have writen a program running on smartphone to make use of the infrared port. I opened COM3 successfully (the IrCOMM is 3), but when I called WriteFile, the program was stalled, and seemed to be waiting for timeout, but it didn't return and I have to reset the phone. I don't know why since the same method works well on my Pocket PC. My smartphone is MPx220. Please help me, thanks! Link to comment Share on other sites More sharing options...
Guest edgecrush3r Posted March 30, 2005 Report Share Posted March 30, 2005 I have writen a program running on smartphone to make use of the infrared port. I opened COM3 successfully (the IrCOMM is 3), but when I called WriteFile, the program was stalled, and seemed to be waiting for timeout, but it didn't return and I have to reset the phone. I don't know why since the same method works well on my Pocket PC. My smartphone is MPx220. Please help me, thanks! <{POST_SNAPBACK}> 1. Please send the code, so I can test if the code works correcly on a C500. 2. Make sure that the IRPort is actually activated (I know it sounds stupid, but it caused me a 1 hour headache once.) 3. Maybe some of the parameters are not supported or different in Windows Mobile. As an alternative, check out the OpenNETCF code sample (RFUtilsVB), which makes use of the OpenNETCF library. Cheers, Tony Tromp Link to comment Share on other sites More sharing options...
Guest candyfeng Posted March 31, 2005 Report Share Posted March 31, 2005 Thank you for your reply. I am using eVC++4.0, and the codes are below. ////Find the IrCOMM port number void CCom::GetIrComm(short &sPort) { DWORD dwSize,dwType,dwData; HKEY hKey; if(RegOpenKeyEx(HKEY_LOCAL_MACHINE,TEXT ("Drivers\\builtIn\\IrCOMM"),0,0,&hKey)==ERROR_SUCCESS) { dwSize=sizeof(dwData); if (RegQueryValueEx(hKey,TEXT("Index"),0,&dwType,(PBYTE)&dwData,&dwSize)==ERROR_SUCCESS) if(dwData<10) { sPort = dwData; } RegCloseKey(hKey); } } Link to comment Share on other sites More sharing options...
Guest candyfeng Posted March 31, 2005 Report Share Posted March 31, 2005 The port number I got is 3. Then I Open COM3 BOOL CIrdaPort::Open(UINT uiPort) { ASSERT(uiPort > 0 && uiPort <= 255); unsigned short strPort[255]; _stprintf(strPort,_T("COM%d:"), uiPort); m_hPort = CreateFile((LPCTSTR) strPort, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (m_hPort == INVALID_HANDLE_VALUE) { return FALSE; } // Set the size of the input and output buffer VERIFY(SetupComm(m_hPort, 2048, 2048)); // Terminates all outstanding read and write operations and clear the buffers VERIFY(PurgeComm(m_hPort, PURGE_TXABORT | PURGE_RXABORT | PURGE_TXCLEAR | PURGE_RXCLEAR)); // Reinitializes all IRDA port settings DCB dcb; dcb.DCBlength = sizeof(DCB); VERIFY(GetCommState(m_hPort, &dcb)); dcb.BaudRate = 19200; dcb.fBinary = TRUE; dcb.fParity = TRUE; dcb.fOutxCtsFlow = FALSE; dcb.fOutxDsrFlow = FALSE; dcb.fDtrControl = DTR_CONTROL_ENABLE; dcb.fDsrSensitivity = FALSE; dcb.fTXContinueOnXoff = TRUE; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fErrorChar = FALSE; dcb.fNull = FALSE; dcb.fRtsControl = RTS_CONTROL_ENABLE; dcb.fAbortonerror = FALSE; dcb.ByteSize = 8; dcb.Parity = NOPARITY; dcb.StopBits = ONESTOPBIT; VERIFY(SetCommState(m_hPort, &dcb)); // Set the timeouts for all read and write operations COMMTIMEOUTS timeouts; VERIFY(GetCommTimeouts(m_hPort, &timeouts)); timeouts.ReadIntervalTimeout = 500; timeouts.ReadTotalTimeoutMultiplier = 5; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 100; timeouts.WriteTotalTimeoutConstant = 0; VERIFY(SetCommTimeouts(m_hPort, &timeouts)); return TRUE; } Link to comment Share on other sites More sharing options...
Guest candyfeng Posted March 31, 2005 Report Share Posted March 31, 2005 Then I send the data. //////Send data DWORD CIrdaPort::Write(BYTE *pData, DWORD dwCount) const { DWORD dwBytesWritten = 0; BOOL bR = WriteFile(m_hPort, pData, dwCount, &dwBytesWritten, NULL); return dwBytesWritten; } And the program blocked here. Link to comment Share on other sites More sharing options...
Guest candyfeng Posted March 31, 2005 Report Share Posted March 31, 2005 Here is the definition of class CIrdaPort //////////////////////////////////////////////////IrdaPort.h class CIrdaPort { public: BOOL Open(UINT uiPort); void Close(); public: DWORD Write(const void* pData, DWORD dwCount) const; HANDLE m_hPort; }; Link to comment Share on other sites More sharing options...
Guest edgecrush3r Posted March 31, 2005 Report Share Posted March 31, 2005 Just out-of interest: Is there a reason why your not using the supplied compact framework library: System.Net.IrDA ? src: http://samples.gotdotnet.com/quickstart/Co...letransfer.aspx Thanks, Tony Link to comment Share on other sites More sharing options...
Guest candyfeng Posted April 1, 2005 Report Share Posted April 1, 2005 But I am not sending data to another smartphone or pocket pc, I am sending data to a hardware I designed which has an infrared port. Link to comment Share on other sites More sharing options...
Guest Gladers Posted April 28, 2005 Report Share Posted April 28, 2005 Can the smartphone emulator use the infra red port from my PC? I don't have 2 smart phones and I want to extend one of my games to use infra red multiplayer. Link to comment Share on other sites More sharing options...
Guest Zone-MR Posted April 28, 2005 Report Share Posted April 28, 2005 (edited) But I am not sending data to another smartphone or pocket pc, I am sending data to a hardware I designed which has an infrared port. Unless your custom hardware supports the full IRDA protocol, including IrCOMM, you want to use Raw IR (Serial IR). COM3 is for IrCOMM, which is part of the IRDA protocol. With IrCOMM, when you want to send some data, the OS will in fact try and verify that there is a compatible device nearby, challenge it for it's name, negotiate a communications mode, etc. Unless your device responds to all these challenges, it will fail. Raw IR (Serial IR) is on COM4. This is a lot simpler. You send a byte, and it's sent straight to the port, in an RS-232 like fashion (except IRDA coding is used - so 'MARK' bits are sent as pulses with width 3/(16*baud). Now for the bad news - and something that's been making me bang my head against the nearest wall for the last few months: http://www.smartphonedn.com/forums/viewtopic.php?t=449 It seems the typhoon phone's CPU (TI OMAP)'s UART does not support SerialIR - it automagically encodes everything you want to send into IRDA frames. So it's simply not possible to do Raw IR on the C500. I'm not sure about other Windows-Mobile based smartphones. If anyone knows, please let me know. Edited April 28, 2005 by Zone-MR Link to comment Share on other sites More sharing options...
Guest MECX Posted May 2, 2005 Report Share Posted May 2, 2005 Unless your custom hardware supports the full IRDA protocol, including IrCOMM, you want to use Raw IR (Serial IR). COM3 is for IrCOMM, which is part of the IRDA protocol. With IrCOMM, when you want to send some data, the OS will in fact try and verify that there is a compatible device nearby, challenge it for it's name, negotiate a communications mode, etc. Unless your device responds to all these challenges, it will fail. Raw IR (Serial IR) is on COM4. This is a lot simpler. You send a byte, and it's sent straight to the port, in an RS-232 like fashion (except IRDA coding is used - so 'MARK' bits are sent as pulses with width 3/(16*baud). Now for the bad news - and something that's been making me bang my head against the nearest wall for the last few months: http://www.smartphonedn.com/forums/viewtopic.php?t=449 It seems the typhoon phone's CPU (TI OMAP)'s UART does not support SerialIR - it automagically encodes everything you want to send into IRDA frames. So it's simply not possible to do Raw IR on the C500. I'm not sure about other Windows-Mobile based smartphones. If anyone knows, please let me know. <{POST_SNAPBACK}> Yes this is the case on the older HTC based smartphones as well (spent a year trying to get decent IR data from an E200) and it looks as tho Motorola are doing the same hardware encoding. The only suggestion i can make (and the way i got around this for my university project) was to use the serial port of the phone (although im sure the USB would work on your moto) and a small piece of hardware to transmit the IR data. The hardware would consist of a clock (at the frequency your tranmitting) anded together with the output signal of your phone going to an IR tranmitter. You may need some buffering (i never actually finished this was just proof of concept). good luck anyway ;) Link to comment Share on other sites More sharing options...
Guest edgecrush3r Posted December 28, 2005 Report Share Posted December 28, 2005 Yes this is the case on the older HTC based smartphones as well (spent a year trying to get decent IR data from an E200) and it looks as tho Motorola are doing the same hardware encoding. The only suggestion i can make (and the way i got around this for my university project) was to use the serial port of the phone (although im sure the USB would work on your moto) and a small piece of hardware to transmit the IR data. The hardware would consist of a clock (at the frequency your tranmitting) anded together with the output signal of your phone going to an IR tranmitter. You may need some buffering (i never actually finished this was just proof of concept). good luck anyway ;) <{POST_SNAPBACK}> I am in severe pain of banging my head against the wall.. :roll: I should have read this a couple of days ago (as it would have saved me from tons of trouble).. Link to comment Share on other sites More sharing options...
Guest Alex_le_brit Posted December 28, 2005 Report Share Posted December 28, 2005 Hijacking this topic slightly, can I just confirm something about the IRDa transceiver unit? is it a simple infra-red LED which transmits pulses of infra-red all at the same frequency? and would it only have a simple 2-pin connection to it? (well two pins for the LED and two pins for the receiver? I'm asking because I would guess if that were the case one could in theory wire a small speaker instead of the LED and a small mic instead of the receiver and actually hear the signal being transmitted. Not that this would neccessarliy be useful for anyting other than confirming transfers, but as I've got my ancient SPV sitting in a draw, I keep looking at it and thinking IRDa to plug in bluetooth headphone adaptor.... and you can get the rest. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now