I'm having issues getting my IrDA communications working on a 1064. It appears to only get locked when I over-ride the autobaud to OSR 32 no matter the baud rate and it's accuracy (still <3%). Does the silicon compensate the OSR for the smaller puls widths or is that the need of the 32 OSR?
Hi,
The Infrared interface of LPUART module covers data rates only between 2.4 kbits/s and 115.2 kbits/s.
There with four options of configurable transmitter narrow pulse: 1/OSR, 2/OSR, 3/OSR or 4/OSR narrow pulse when IR is enabled. Common pulse widths are 3/16, 1/16, 1/32 or 1/4 of the bit length. These can be configured by selecting the appropriate oversample ratio and pulse width.
For example: Set narrow pulse width equal 3/16, the OSR need be 16 and TNP set to 3/OSR.
TNP bits at LPUART Modem IrDA Register (MODIR)
Have a great day,
Mike
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi,
Please check the IrDA communication pulse width.
The RT1064 LPUART shows Infrared decoder with Noise filtering feature:
If there exists the pulse width smaller than on oversampling baud clock width?
Thanks for the attention.
best regards,
Mike
I kind of gotten it working. IrDA being half duplex helps a lot if Rx or Tx one of them should be inverted so they fight less. The baud rate still only works at 9600 when set to 32 OSR. The pulses are all measured correctly. It gets data, but is wrong and fails my CRC check when I choose the wrong CRC. The autobaud code in the FSL code is mildly wrong, as it trucates decimal points in the math in casting as Ints, but that didn't solve the problem either. For now I'll just force OSR of 32 for 9600.
Hello Steven,
Many thanks for the feedback.
Could you help to provide more detailed info about this issue?
Such as captured communication signals, related software code, related hardware circuit.
Then I could ask product team to analyse this issue and try to find the root cause. Thanks.
best regards,
Mike