IR: Fix crash on duty_cycle=1

[Willy-JL]

What's new

• infrared_signal_is_raw_valid() says that duty_cycle > 1 is invalid
• infrared_worker_set_raw_signal() checks duty_cycle < 1
• therefore, duty_cycle == 1 fails the check, when really it should be accepted

Verification

• send an infrared raw with duty_cycle: 1

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[skotopes]

To be honest duty_cycle=1 is an invalid value that we never tested. It kinda make no sense. It means that no carrier present. Do you have real life examples for this change?

[Willy-JL]

I got this report from a friend, they had an IR file with all raws at duty cycle 1. I am not sure if it was captured or generated, but from what they were saying, it seemed to work correctly and do what it was intended to do on older firmware. With furi checks now, it would crash.

[skotopes]

I got this report from a friend, they had an IR file with all raws at duty cycle 1. I am not sure if it was captured or generated, but from what they were saying, it seemed to work correctly and do what it was intended to do on older firmware. With furi checks now, it would crash.

That was clearly generated file. What happens with duty cycle 1.0: there will be no carrier frequency. We really'd like to know what system actually uses that kind of signal.

[Willy-JL]

He told me it was set to 1 on purpose and used to test accurate IR measuring devices

[skotopes]

@Willy-JL this will work, but not because it was designed to do so.

I highly don't recommend to use it for modulation debugging. Also after some experiments I found that some timings are slightly off.

I'll merge this PR, but more research required.