IR: few fixes, additions and ENE driver

It is prefectly possible to have ir_raw_event_work running concurently on two cpus, thus we must protect it from that situation.

Maybe better solution is to ditch the workqueue at all and use good 'ol thread per receiver, and just wake it up...

Signed-off-by Maxim Levitsky <[email protected]>

---
 drivers/media/IR/ir-raw-event.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

drivers/media/IR/ir-raw-event.c +5 -2

index 9d5c029..4098748 100644
@@ -40,13 +40,16 @@ static void ir_raw_event_work(struct work_struct *work)
 	struct ir_raw_event_ctrl *raw =
 		container_of(work, struct ir_raw_event_ctrl, rx_work);
 
+	mutex_lock(&ir_raw_handler_lock);
+
 	while (kfifo_out(&raw->kfifo, &ev, sizeof(ev)) == sizeof(ev)) {
-		mutex_lock(&ir_raw_handler_lock);
 		list_for_each_entry(handler, &ir_raw_handler_list, list)
 			handler->decode(raw->input_dev, ev);
-		mutex_unlock(&ir_raw_handler_lock);
 		raw->prev_ev = ev;
 	}
+
+	mutex_unlock(&ir_raw_handler_lock);
+
 }
 
 /**

Quoted 3 lines · Maxim Levitsky

It is prefectly possible to have ir_raw_event_work running concurently on two cpus, thus we must protect it from that situation.

Yup, the work is marked as not pending (and hence reschedulable) just before the work handler is run.

Quoted 2 lines

Maybe better solution is to ditch the workqueue at all and use good 'ol thread per receiver, and just wake it up...

I suppose you could also use a single threaded workqueue instead of a mutex, and let a bit test provide exclusivity. With the mutex, when the second thread finally obtains the lock, there will likely not be anything for it to do.

Repeat space is 4 units, not 8.
Current code would never trigger a repeat.

However that isn't true for NECX, so repeat there
must be handled differently.

Signed-off-by Maxim Levitsky <[email protected]>

---
 drivers/media/IR/ir-nec-decoder.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

drivers/media/IR/ir-nec-decoder.c +1 -1

index 52e0f37..1c0cf03 100644
@@ -20,7 +20,7 @@
 #define NEC_HEADER_PULSE	(16 * NEC_UNIT)
 #define NECX_HEADER_PULSE	(8  * NEC_UNIT) /* Less common NEC variant */
 #define NEC_HEADER_SPACE	(8  * NEC_UNIT)
-#define NEC_REPEAT_SPACE	(8  * NEC_UNIT)
+#define NEC_REPEAT_SPACE	(4  * NEC_UNIT)
 #define NEC_BIT_PULSE		(1  * NEC_UNIT)
 #define NEC_BIT_0_SPACE		(1  * NEC_UNIT)
 #define NEC_BIT_1_SPACE		(3  * NEC_UNIT)

note that error_adjustment module option is added. This allows to reduce input samples by a percent. This makes input on my system more correct.

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know what adjustments to apply to fan tachometer input. Maybe it is accurate already.

Quoted 4 lines · Maxim Levitsky

note that error_adjustment module option is added. This allows to reduce input samples by a percent. This makes input on my system more correct.

Quoted 5 lines

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know what adjustments to apply to fan tachometer input. Maybe it is accurate already.

Do you have the manual for the ENE chip in English? or do you read Chinese?

Maybe you can figure out why the readings are off by 4%. I suspect that someone has set a clock divider wrong when programming the chip. For example setting the divider for a 25Mhz clock when the clock is actually 26Mhz would cause the error you are seeing. Or they just made a mistake in computing the divisor. It is probably a bug in the BIOS of your laptop. If that's the case you could add a quirk in the system boot code to fix the register setting.

Quoted 6 lines · Jon Smirl

Quoted 4 lines · Maxim Levitsky

note that error_adjustment module option is added. This allows to reduce input samples by a percent. This makes input on my system more correct.

Quoted 7 lines

Quoted 5 lines

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know what adjustments to apply to fan tachometer input. Maybe it is accurate already.

Do you have the manual for the ENE chip in English? or do you read Chinese?

The datasheet for a similar chip, the KB3700, is out there in English, but it doesn't have CIR.

You might find these links mildly interesting:

http://www.coreboot.org/Embedded_controller
http://wiki.laptop.org/go/Embedded_controller
http://lists.laptop.org/pipermail/openec/2008-July/000108.html

Regards,
Andy

Quoted 7 lines

Maybe you can figure out why the readings are off by 4%. I suspect that someone has set a clock divider wrong when programming the chip. For example setting the divider for a 25Mhz clock when the clock is actually 26Mhz would cause the error you are seeing. Or they just made a mistake in computing the divisor. It is probably a bug in the BIOS of your laptop. If that's the case you could add a quirk in the system boot code to fix the register setting.

Quoted 15 lines · Andy Walls

Quoted 6 lines · Jon Smirl

Quoted 4 lines · Maxim Levitsky

note that error_adjustment module option is added. This allows to reduce input samples by a percent. This makes input on my system more correct.

Quoted 7 lines

Quoted 5 lines

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know what adjustments to apply to fan tachometer input. Maybe it is accurate already.

Do you have the manual for the ENE chip in English? or do you read Chinese?

Quoted 8 lines

The datasheet for a similar chip, the KB3700, is out there in English, but it doesn't have CIR.

You might find these links mildly interesting:

http://www.coreboot.org/Embedded_controller
http://wiki.laptop.org/go/Embedded_controller
http://lists.laptop.org/pipermail/openec/2008-July/000108.html

Nope, I have read that.

Quoted 11 lines

Regards,
Andy

Quoted 7 lines

Maybe you can figure out why the readings are off by 4%. I suspect that someone has set a clock divider wrong when programming the chip. For example setting the divider for a 25Mhz clock when the clock is actually 26Mhz would cause the error you are seeing. Or they just made a mistake in computing the divisor. It is probably a bug in the BIOS of your laptop.  If that's the case you could add a quirk in the system boot code to fix the register setting.

I figured out how windows driver compensates for the offset, and do the same in my driver. I think the problem is solved.

Best regards,
Maxim Levitsky

Quoted 38 lines · Maxim Levitsky

Quoted 15 lines · Andy Walls

Quoted 6 lines · Jon Smirl

Quoted 4 lines · Maxim Levitsky

note that error_adjustment module option is added. This allows to reduce input samples by a percent. This makes input on my system more correct.

Quoted 7 lines

Quoted 5 lines

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know what adjustments to apply to fan tachometer input. Maybe it is accurate already.

Do you have the manual for the ENE chip in English? or do you read Chinese?

Quoted 8 lines

The datasheet for a similar chip, the KB3700, is out there in English, but it doesn't have CIR.

You might find these links mildly interesting:

http://www.coreboot.org/Embedded_controller
http://wiki.laptop.org/go/Embedded_controller
http://lists.laptop.org/pipermail/openec/2008-July/000108.html

Nope, I have read that.

Quoted 11 lines

Regards,
Andy

Quoted 7 lines

Maybe you can figure out why the readings are off by 4%. I suspect that someone has set a clock divider wrong when programming the chip. For example setting the divider for a 25Mhz clock when the clock is actually 26Mhz would cause the error you are seeing. Or they just made a mistake in computing the divisor. It is probably a bug in the BIOS of your laptop. If that's the case you could add a quirk in the system boot code to fix the register setting.

Quoted 3 lines

I figured out how windows driver compensates for the offset, and do the same in my driver. I think the problem is solved.

Should that be a <= or >= instead of !=?
+ if (pll_freq != 1000)

Programming the PLL wrong would cause the 4% error.

       hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
       old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);

(quoted diff) +11 -0

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
+
+       if (pll_freq != 1000)
+               dev->rx_period_adjust = 4;
+       else
+               dev->rx_period_adjust = 2;
+
+
+       ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
+
       if (hw_revision == 0xFF) {

Quoted 8 lines

Best regards,
Maxim Levitsky

Quoted 39 lines · Jon Smirl

Quoted 38 lines · Maxim Levitsky

Quoted 15 lines · Andy Walls

Quoted 6 lines · Jon Smirl

Quoted 4 lines · Maxim Levitsky

note that error_adjustment module option is added. This allows to reduce input samples by a percent. This makes input on my system more correct.

Quoted 7 lines

Quoted 5 lines

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know what adjustments to apply to fan tachometer input. Maybe it is accurate already.

Do you have the manual for the ENE chip in English? or do you read Chinese?

Quoted 8 lines

The datasheet for a similar chip, the KB3700, is out there in English, but it doesn't have CIR.

You might find these links mildly interesting:

http://www.coreboot.org/Embedded_controller
http://wiki.laptop.org/go/Embedded_controller
http://lists.laptop.org/pipermail/openec/2008-July/000108.html

Nope, I have read that.

Quoted 11 lines

Regards,
Andy

Quoted 7 lines

Maybe you can figure out why the readings are off by 4%. I suspect that someone has set a clock divider wrong when programming the chip. For example setting the divider for a 25Mhz clock when the clock is actually 26Mhz would cause the error you are seeing. Or they just made a mistake in computing the divisor. It is probably a bug in the BIOS of your laptop.  If that's the case you could add a quirk in the system boot code to fix the register setting.

Quoted 6 lines

Quoted 3 lines

I figured out how windows driver compensates for the offset, and do the same in my driver. I think the problem is solved.

Should that be a <= or >= instead of !=?
+       if (pll_freq != 1000)

This is how its done in windows driver.

Quoted 29 lines

Programming the PLL wrong would cause the 4% error.

       hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION); old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

drivers/media/IR/ene_ir.c +9 -0

+
+       if (pll_freq != 1000)
+               dev->rx_period_adjust = 4;
+       else
+               dev->rx_period_adjust = 2;
+
+
+       ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
+

       if (hw_revision == 0xFF) {

Quoted 5 lines

Best regards,
Maxim Levitsky

Quoted 40 lines · Maxim Levitsky

Quoted 39 lines · Jon Smirl

Quoted 38 lines · Maxim Levitsky

Quoted 15 lines · Andy Walls

Quoted 6 lines · Jon Smirl

Quoted 4 lines · Maxim Levitsky

note that error_adjustment module option is added. This allows to reduce input samples by a percent. This makes input on my system more correct.

Quoted 7 lines

Quoted 5 lines

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know what adjustments to apply to fan tachometer input. Maybe it is accurate already.

Do you have the manual for the ENE chip in English? or do you read Chinese?

Quoted 8 lines

The datasheet for a similar chip, the KB3700, is out there in English, but it doesn't have CIR.

You might find these links mildly interesting:

http://www.coreboot.org/Embedded_controller
http://wiki.laptop.org/go/Embedded_controller
http://lists.laptop.org/pipermail/openec/2008-July/000108.html

Nope, I have read that.

Quoted 11 lines

Regards,
Andy

Quoted 7 lines

Maybe you can figure out why the readings are off by 4%. I suspect that someone has set a clock divider wrong when programming the chip. For example setting the divider for a 25Mhz clock when the clock is actually 26Mhz would cause the error you are seeing. Or they just made a mistake in computing the divisor. It is probably a bug in the BIOS of your laptop.  If that's the case you could add a quirk in the system boot code to fix the register setting.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

I figured out how windows driver compensates for the offset, and do the same in my driver. I think the problem is solved.

Should that be a <= or >= instead of !=?
+       if (pll_freq != 1000)

This is how its done in windows driver.

That doesn't mean it is bug free.

Experimenting with changing the PLL frequency register may correct the error.  Try taking 96% of pll_freq and write it back into these register. This would be easy to fix with a manual. The root problem is almost certainly a bug in the way the PLLs were programmed.

I don't like putting in fudge factors like the 4% correction. What happens if a later version of the hardware has fixed firmware? I normal user is never going to figure out that they need to change the fudge factor.

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

+

Quoted 22 lines

Quoted 22 lines

Programming the PLL wrong would cause the 4% error.

       hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION); old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

(quoted diff) +9 -0

+
+       if (pll_freq != 1000)
+               dev->rx_period_adjust = 4;
+       else
+               dev->rx_period_adjust = 2;
+
+
+       ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
+

       if (hw_revision == 0xFF) {

Quoted 1 line

Quoted 10 lines

Quoted 7 lines

Quoted 4 lines

Best regards,
Maxim Levitsky

--
Jon Smirl
[email protected]

Quoted 45 lines · Jon Smirl

Quoted 44 lines · Maxim Levitsky

Quoted 43 lines · Jon Smirl

Quoted 41 lines · Maxim Levitsky

Quoted 15 lines · Andy Walls

Quoted 6 lines · Jon Smirl

Quoted 4 lines · Maxim Levitsky

note that error_adjustment module option is added. This allows to reduce input samples by a percent. This makes input on my system more correct.

Quoted 7 lines

Quoted 5 lines

Default is 4% as it works best here.

Note that only normal input is adjusted. I don't know what adjustments to apply to fan tachometer input. Maybe it is accurate already.

Do you have the manual for the ENE chip in English? or do you read Chinese?

Quoted 8 lines

The datasheet for a similar chip, the KB3700, is out there in English, but it doesn't have CIR.

You might find these links mildly interesting:

http://www.coreboot.org/Embedded_controller
http://wiki.laptop.org/go/Embedded_controller
http://lists.laptop.org/pipermail/openec/2008-July/000108.html

Nope, I have read that.

Quoted 11 lines

Regards,
Andy

Quoted 7 lines

Maybe you can figure out why the readings are off by 4%. I suspect that someone has set a clock divider wrong when programming the chip. For example setting the divider for a 25Mhz clock when the clock is actually 26Mhz would cause the error you are seeing. Or they just made a mistake in computing the divisor. It is probably a bug in the BIOS of your laptop. If that's the case you could add a quirk in the system boot code to fix the register setting.

I figured out how windows driver compensates for the offset, and do the same in my driver. I think the problem is solved.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Should that be a <= or >= instead of !=?
+ if (pll_freq != 1000)

This is how its done in windows driver.

That doesn't mean it is bug free.

Quoted 10 lines

Experimenting with changing the PLL frequency register may correct the error. Try taking 96% of pll_freq and write it back into these register. This would be easy to fix with a manual. The root problem is almost certainly a bug in the way the PLLs were programmed.

I don't like putting in fudge factors like the 4% correction. What happens if a later version of the hardware has fixed firmware? I normal user is never going to figure out that they need to change the fudge factor.

Review

Quoted 3 lines

(quoted diff) +2 -0

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

I can understand the shift of the high bits, but that shift of the low bits is unlikely. A manual would tell us if it is right.

Quoted 8 lines · Jon Smirl

Quoted 6 lines · Jon Smirl

On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <[email protected]> wrote:

(quoted diff) +2 -0

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

Quoted 3 lines

I can understand the shift of the high bits, but that shift of the low bits is unlikely. A manual would tell us if it is right.

This shift is correct (according to datasheet, which contains mostly useless info, but it does dociment this reg briefly.)

Quoted 14 lines · Maxim Levitsky

Quoted 13 lines · Jon Smirl

Review

Quoted 6 lines · Jon Smirl

On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <[email protected]> wrote:

(quoted diff) +2 -0

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

I can understand the shift of the high bits, but that shift of the low bits is unlikely. A manual would tell us if it is right.

Quoted 2 lines

This shift is correct (according to datasheet, which contains mostly useless info, but it does dociment this reg briefly.)

The KB3700 series datasheet indicates that the value from ENE_PLLFRL should be shifted by >> 4 bits, not by >> 2. Of course, the KB3700 isn't the exact same chip.

Quoted 15 lines · Andy Walls

Quoted 14 lines · Maxim Levitsky

Quoted 13 lines · Jon Smirl

Quoted 6 lines · Jon Smirl

On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <[email protected]> wrote:

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

I can understand the shift of the high bits, but that shift of the low bits is unlikely.  A manual would tell us if it is right.

Quoted 6 lines

Quoted 2 lines

This shift is correct (according to datasheet, which contains mostly useless info, but it does dociment this reg briefly.)

The KB3700 series datasheet indicates that the value from ENE_PLLFRL should be shifted by >> 4 bits, not by >> 2.  Of course, the KB3700 isn't the exact same chip.

You are right about that, thanks!

Best regards,
Maxim Levitsky

Quoted 16 lines · Maxim Levitsky

Quoted 15 lines · Andy Walls

Quoted 14 lines · Maxim Levitsky

Quoted 13 lines · Jon Smirl

Review

Quoted 6 lines · Jon Smirl

On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <[email protected]> wrote:

(quoted diff) +2 -0

+       pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+               (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);

I can understand the shift of the high bits, but that shift of the low bits is unlikely. A manual would tell us if it is right.

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

This shift is correct (according to datasheet, which contains mostly useless info, but it does dociment this reg briefly.)

The KB3700 series datasheet indicates that the value from ENE_PLLFRL should be shifted by >> 4 bits, not by >> 2. Of course, the KB3700 isn't the exact same chip.

You are right about that, thanks!

I looked at KB3700 manual. It says it is trying to make a 32Mhz clock by multiplying 32.768Khz * 1000.

32,768 * 1000 = 32.768Mhz is a 2.4% error.

When you are computing the timings of the pulses did you assume a 32Mhz clock? It looks like the clock is actuall 32.768Mhz.

Quoted 7 lines · Jon Smirl

Quoted 5 lines · Jon Smirl

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Should that be a <= or >= instead of !=?
+ if (pll_freq != 1000)

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

This is how its done in windows driver.

That doesn't mean it is bug free.

This PLL frequency is likely to be chip internal frequency. And windows driver doesn't touch it.
Its embedded controller, so I don't want to touch things I am not sure about.

Quoted 9 lines

Quoted 9 lines

Experimenting with changing the PLL frequency register may correct the error. Try taking 96% of pll_freq and write it back into these register. This would be easy to fix with a manual. The root problem is almost certainly a bug in the way the PLLs were programmed.

I don't like putting in fudge factors like the 4% correction. What happens if a later version of the hardware has fixed firmware? I normal user is never going to figure out that they need to change the fudge factor.

I don't think that is a hardware bug, rather a limitation.

Lets leave it as is.
I will soon publish the driver on launchpad or something like that and try to contact users I debugged that driver with, and then see what ranges PLL register takes.

I think you won't be able to fix the problem conclusively either way.  A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

Regards,
Andy

Quoted 11 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case. The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+. The 4% error in this driver is because the hardware is not being programmed accurately. This needs to be fixed in the driver and not in the upper layers.

Quoted 11 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case. The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+. The 4% error in this driver is because the hardware is not being programmed accurately. This needs to be fixed in the driver and not in the upper layers.

How is sample period being computed, where is the complete source to this driver?

       dev->tx_period = 32;

Where is sample_period computed?

(quoted diff) +5 -0

@@ -672,13 +583,25 @@ static irqreturn_t ene_isr(int irq, void *data)
                       pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
                       hw_value &= ENE_SAMPLE_VALUE_MASK;
                       hw_sample = hw_value * sample_period;
+
+                       if (dev->rx_period_adjust) {
+                               hw_sample *= (100 - dev->rx_period_adjust);
+                               hw_sample /= 100;
+                       }
               }
 

I suspect sample_period is set to 32us. For 32.768Mhz the period needs to be 30.5us. I don't see the code for how it was computed.

You have to be careful with rounding errors when doing this type of computation. What looks like a minor error can amplify into a large error. Sometimes I do the math in 64b ints just to keep the round off errors from accumulating. Instead of doing the math in calculator and plugging in 32. Use #defines and do the math in the

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way.  A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+.

4%.

Hi Jon,

Quoted 10 lines · Jon Smirl

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way.  A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%).  The crystals used in electronics are accurate to 0.0001%+.

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

4%.

Christoph

Quoted 29 lines · Christoph Bartelmus

Hi Jon,

Quoted 10 lines · Jon Smirl

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way.  A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%).  The crystals used in electronics are accurate to 0.0001%+.

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error and caused the JVC code to be misclassified as NEC.

I think he said lirc was misclassifying it too. So we both did the same thing.

Quoted 3 lines

Christoph

--
Jon Smirl
[email protected]

Quoted 27 lines · Christoph Bartelmus

Hi Jon,

Quoted 10 lines · Jon Smirl

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case. The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+.

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

Quoted 3 lines

For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error

and caused the JVC code to be
misclassified as NEC.

Quoted 28 lines · Jon Smirl

Quoted 27 lines · Christoph Bartelmus

Hi Jon,

Quoted 10 lines · Jon Smirl

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way.  A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%).  The crystals used in electronics are accurate to 0.0001%+.

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

Quoted 8 lines

Quoted 3 lines

For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error

Hi Jon,

Hmmm.  Leader marks are, by protocol design, there to give time for the receiver's AGC to settle.  We should make it OK to miss somewhat large portions of leader marks.  I'm not sure what the harm is in accepting too long of a leader mark, but I'm pretty sure a leader mark that is too long will always be due to systematic error and not noise errors.

However, if we know we have systematic errors caused by unknowns, we should be designing and implementing a decoding system that reasonably deals with those systematic errors.  Again the part of the system almost completely out of our control is the remote controls, and we *have no control* over systematic errors introduced by remotes.

Obviously we want to reduce or eliminate systematic errors by determining the unknowns and undoing their effects or by compensating for their overall effect.  But in the case of the ENE receiver driver, you didn't seem to like the Maxim's software compensation for the systematic receiver errors.

Quoted 2 lines

and caused the JVC code to be
misclassified as NEC.

I still have not heard why we need protocol discrimination/classifcation in the kernel.  Doing discrimination between two protocols with such close timings is whose requirement again?

Since these two protocols have such close timings that systematic errors can cause misclassification when using simple mark or space measurements against fixed thresholds, it indicates that a more sophisticated discrimination mechanism would be needed.  Perhaps one that takes multiple successive measurements into account?

Regards,
Andy

Quoted 46 lines · Andy Walls

Quoted 28 lines · Jon Smirl

Quoted 27 lines · Christoph Bartelmus

Hi Jon,

Quoted 10 lines · Jon Smirl

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case. The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%). The crystals used in electronics are accurate to 0.0001%+.

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

Quoted 8 lines

Quoted 3 lines

For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error

Hi Jon,

Hmmm. Leader marks are, by protocol design, there to give time for the receiver's AGC to settle. We should make it OK to miss somewhat large portions of leader marks. I'm not sure what the harm is in accepting too long of a leader mark, but I'm pretty sure a leader mark that is too long will always be due to systematic error and not noise errors.

Quoted 5 lines

However, if we know we have systematic errors caused by unknowns, we should be designing and implementing a decoding system that reasonably deals with those systematic errors. Again the part of the system almost completely out of our control is the remote controls, and we *have no control* over systematic errors introduced by remotes.

We haven't encountered remotes with systematic errors. If remotes had large errors in them they wouldn't be able to reliably control their target devices. Find a remote that won't work with the protocol engines and a reasonably accurate receiver.

Quoted 1 line

Quoted 5 lines

Obviously we want to reduce or eliminate systematic errors by determining the unknowns and undoing their effects or by compensating for their overall effect. But in the case of the ENE receiver driver, you didn't seem to like the Maxim's software compensation for the systematic receiver errors.

I would be happier if we could track down the source of the error instead of sticking a bandaid on at the end of the process.

Quoted 7 lines

Quoted 3 lines

and caused the JVC code to be
misclassified as NEC.

I still have not heard why we need protocol discrimination/classifcation in the kernel. Doing discrimination between two protocols with such close timings is whose requirement again?

If we don't do protocol engines we have to revert back to raw recording and having everyone train the system with their remotes. The goal is to eliminate the training step. We would also have to have large files (LIRC configs) for building the keymaps and a new API to deal with them. With the engines the key presses are identified by short strings.

A use case: install mythtv, add an IR receiver. Myth UI says to set your universal remote to a Motorola DVR profile. Remote works - no training step needed.

LIRC has protocol engines too. irrecord first tries to fit the remote into a protocol engine. If it can't it reverts to raw mode. Let's analyze those cases where lirc ends up in raw mode and see if we can figure out what's going wrong.

For example I know of two things that will trip up irrecord that are fixed in the kernel system
1) the ene driver. we know now it had a 4% error in the reported periods

2) Sony remotes - they mix protocols on a single remote.

Quoted 5 lines

Since these two protocols have such close timings that systematic errors can cause misclassification when using simple mark or space measurements against fixed thresholds, it indicates that a more sophisticated discrimination mechanism would be needed. Perhaps one that takes multiple successive measurements into account?

If we get to the point where we need more sophisticated classifications we can build it. But are we at that point yet? I'd prefer to initially leave everything pretty strict as a way of flushing out driver implementation bugs.

Find some remotes and receivers that break the current system.

Quoted 5 lines

Regards,
Andy

Quoted 49 lines · Andy Walls

Quoted 33 lines · Jon Smirl

Quoted 31 lines · Christoph Bartelmus

Hi Jon,

Quoted 11 lines · Jon Smirl

Quoted 9 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way.. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%).  The crystals used in electronics are accurate to 0.0001%+.

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 6 lines

Quoted 1 line

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error

Hi Jon,

Hmmm.  Leader marks are, by protocol design, there to give time for the receiver's AGC to settle.  We should make it OK to miss somewhat large portions of leader marks.  I'm not sure what the harm is in accepting too long of a leader mark, but I'm pretty sure a leader mark that is too long will always be due to systematic error and not noise errors.

Quoted 5 lines

However, if we know we have systematic errors caused by unknowns, we should be designing and implementing a decoding system that reasonably deals with those systematic errors.  Again the part of the system almost completely out of our control is the remote controls, and we *have no control* over systematic errors introduced by remotes.

We haven't encountered remotes with systematic errors. If remotes had large errors in them they wouldn't be able to reliably control their target devices. Find a remote that won't work with the protocol engines and a reasonably accurate receiver.

Quoted 6 lines

Obviously we want to reduce or eliminate systematic errors by determining the unknowns and undoing their effects or by compensating for their overall effect.  But in the case of the ENE receiver driver, you didn't seem to like the Maxim's software compensation for the systematic receiver errors.

I would be happier if we could track down the source of the error instead of sticking a bandaid on at the end of the process.

Quoted 6 lines

Quoted 2 lines

and caused the JVC code to be
misclassified as NEC.

I still have not heard why we need protocol discrimination/classifcation in the kernel.  Doing discrimination between two protocols with such close timings is whose requirement again?

If we don't do protocol engines we have to revert back to raw recording and having everyone train the system with their remotes. The goal is to eliminate the training step. We would also have to have large files (LIRC configs) for building the keymaps and a new API to deal with them. With the engines the key presses are identified by short strings.

A use case: install mythtv, add an IR receiver. Myth UI says to set your universal remote to a Motorola DVR profile. Remote works - no training step needed.

LIRC has protocol engines too. irrecord first tries to fit the remote into a protocol engine.

If it can't it reverts to raw mode. Let's
analyze those cases where lirc ends up in raw mode and see if we can figure out what's going wrong.

For example I know of two things that will trip up irrecord that are fixed in the kernel system
1) the ene driver. we know now it had a 4% error in the reported periods

2) Sony remotes - they mix protocols on a single remote.

Quoted 5 lines

Since these two protocols have such close timings that systematic errors can cause misclassification when using simple mark or space measurements against fixed thresholds, it indicates that a more sophisticated discrimination mechanism would be needed.  Perhaps one that takes multiple successive measurements into account?

If we get to the point where we need more sophisticated classifications we can build it. But are we at that point yet? I'd prefer to initially leave everything pretty strict as a way of flushing out driver implementation bugs.

Find some remotes and receivers that break the current system.

Quoted 5 lines

Regards,
Andy

On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <[email protected]> wrote:

Quoted 5 lines

Since these two protocols have such close timings that systematic errors can cause misclassification when using simple mark or space measurements against fixed thresholds, it indicates that a more sophisticated discrimination mechanism would be needed.  Perhaps one that takes multiple successive measurements into account?

If we get to the point where we need more sophisticated classifications we can build it. But are we at that point yet? I'd prefer to initially leave everything pretty strict as a way of flushing out driver implementation bugs.

Find some remotes and receivers that break the current system.

Quoted 1 line · Jon Smirl

On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <[email protected]> wrote:

...

Quoted 11 lines

Quoted 5 lines

Since these two protocols have such close timings that systematic errors can cause misclassification when using simple mark or space measurements against fixed thresholds, it indicates that a more sophisticated discrimination mechanism would be needed.  Perhaps one that takes multiple successive measurements into account?

If we get to the point where we need more sophisticated classifications we can build it. But are we at that point yet? I'd prefer to initially leave everything pretty strict as a way of flushing out driver implementation bugs.

Quoted 1 line

Find some remotes and receivers that break the current system.

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly decode in-kernel for the life of me. I got lirc_streamzap 99% of the way ported over the weekend, but this remote just won't decode correctly w/the in-kernel RC5 decoder.

Working:
Streamzap receiver + RC6 (MCE) remote, in-kernel decoding Streamzap receiver + RC5 (Streamzap) remote, lirc decoding

Not working:
Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding

Failure mode is identical between the two, leading me to believe my streamzap port is good to go, we just have an issue to track down with rc5 decoding.

Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial space provided by both receivers, then gets rolling with (I believe) the first pulse. It then gets all the way to STATE_FINISHED, and bails, because it should be on a space there, but its on a pulse.

I've twiddled the decoder to proceed even if its a pulse, but the resulting decoding is still no good, as multiple adjacent keys (which have proper decoded values that only differ by 1, per lirc decoding) get decoded to the same value as one another.

Still poking around trying to figure out the problem, but here's what the (slightly modified to not bail when it gets to STATE_FINISHED with a pulse) rc5 decoder is seeing/doing:

ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse)
ir_rc5_decode: RC5 usually ends w/space, wtf?
ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0)
ir_getkeycode: unknown key for scancode 0x1129

This was for the OK button on the remote, which in lircd, decodes to scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons. At least, I think I'm decoding lircd.conf correctly. See here to be sure:

http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap

--
Jarod Wilson
[email protected]

Quoted 4 lines

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly decode in-kernel for the life of me. I got lirc_streamzap 99% of the way ported over the weekend, but this remote just won't decode correctly w/the in-kernel RC5 decoder.

Manchester encoding may need a decoder that waits to get 2-3 edge changes before deciding what the first bit. As you decode the output is always a couple bits behind the current input data.

You can build of a table of states
L0 S1 S0 L1 - emit a 1, move forward an edge
S0 S1 L0 L1 - emit a 0, move forward an edge

By doing it that way you don't have to initially figure out the bit clock.

The current decoder code may not be properly tracking the leading zero. In Manchester encoding it is illegal for a bit to be 11 or 00. They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is off by 1/2 a bit cycle.

Did you note the comment that Extended RC-5 has only a single start bit instead of two?

Hi!

Jon Smirl "[email protected]" wrote:
[...]

Quoted 20 lines

Quoted 4 lines

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly decode in-kernel for the life of me. I got lirc_streamzap 99% of the way ported over the weekend, but this remote just won't decode correctly w/the in-kernel RC5 decoder.

Manchester encoding may need a decoder that waits to get 2-3 edge changes before deciding what the first bit. As you decode the output is always a couple bits behind the current input data.

You can build of a table of states
L0 S1 S0 L1  - emit a 1, move forward an edge
S0 S1 L0 L1 - emit a 0, move forward an edge

By doing it that way you don't have to initially figure out the bit clock.

The current decoder code may not be properly tracking the leading zero. In Manchester encoding it is illegal for a bit to be 11 or 00. They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is off by 1/2 a bit cycle.

Quoted 2 lines

Did you note the comment that Extended RC-5 has only a single start bit instead of two?

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13. The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5. Did I mention this already? Yes. ;-)

Christoph

Quoted 24 lines · Christoph Bartelmus

Hi!

Jon Smirl "[email protected]" wrote:
[...]

Quoted 20 lines

Quoted 4 lines

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly decode in-kernel for the life of me. I got lirc_streamzap 99% of the way ported over the weekend, but this remote just won't decode correctly w/the in-kernel RC5 decoder.

Manchester encoding may need a decoder that waits to get 2-3 edge changes before deciding what the first bit. As you decode the output is always a couple bits behind the current input data.

You can build of a table of states
L0 S1 S0 L1  - emit a 1, move forward an edge
S0 S1 L0 L1 - emit a 0, move forward an edge

By doing it that way you don't have to initially figure out the bit clock.

The current decoder code may not be properly tracking the leading zero. In Manchester encoding it is illegal for a bit to be 11 or 00. They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is off by 1/2 a bit cycle.

Quoted 8 lines

Quoted 2 lines

Did you note the comment that Extended RC-5 has only a single start bit instead of two?

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13. The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5. Did I mention this already? Yes. ;-)

If the remote is sending a weird protocol then there are several choices:
1) implement raw mode
2) make a Stream-Zap protocol engine (it would be a 14b version of
RC-5). Standard RC5 engine will still reject the messages.
3) throw away your Stream-Zap remotes

I'd vote for #3, but #2 will probably make people happier.

Quoted 34 lines · Jon Smirl

Quoted 24 lines · Christoph Bartelmus

Hi!

Jon Smirl "[email protected]" wrote:
[...]

Quoted 20 lines

Quoted 4 lines

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly decode in-kernel for the life of me. I got lirc_streamzap 99% of the way ported over the weekend, but this remote just won't decode correctly w/the in-kernel RC5 decoder.

Manchester encoding may need a decoder that waits to get 2-3 edge changes before deciding what the first bit. As you decode the output is always a couple bits behind the current input data.

You can build of a table of states
L0 S1 S0 L1  - emit a 1, move forward an edge
S0 S1 L0 L1 - emit a 0, move forward an edge

By doing it that way you don't have to initially figure out the bit clock.

The current decoder code may not be properly tracking the leading zero. In Manchester encoding it is illegal for a bit to be 11 or 00. They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is off by 1/2 a bit cycle.

Quoted 8 lines

Quoted 2 lines

Did you note the comment that Extended RC-5 has only a single start bit instead of two?

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13. The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5. Did I mention this already? Yes. ;-)

Quoted 7 lines

If the remote is sending a weird protocol then there are several choices:
  1) implement raw mode
  2) make a Stream-Zap protocol engine (it would be a 14b version of RC-5). Standard RC5 engine will still reject the messages.
  3) throw away your Stream-Zap remotes

I'd vote for #3, but #2 will probably make people happier.

Hm. Yeah, I know a few people who are quite attached to their Streamzap remotes. I'm not a particularly big fan of it, I only got the thing off ebay to have the hardware so I could work on the driver. :) So yeah, #3 is probably not the best route. But I don't know that I'm a huge fan of #2 either. Another decoder engine just for one quirky remote seems excessive, and there's an option #4:

4) just keep passing data out to lirc by default.

Let lircd handle the default remote in this case. If you want to use another remote that actually uses a standard protocol, and want to use in-kernel decoding for that, its just an ir-keytable call away.

For giggles, I may tinker with implementing another decoder engine though, if only to force myself to actually pay more attention to protocol specifics. For the moment, I'm inclined to go ahead with the streamzap port as it is right now, and include either an empty or not-empty, but not-functional key table.

--
Jarod Wilson
[email protected]

Quoted 2 lines · Jarod Wilson

Quoted 1 line · Jon Smirl

On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <[email protected]> wrote:

Quoted 14 lines

Quoted 6 lines

Quoted 5 lines

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13. The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5. Did I mention this already? Yes. ;-)

Quoted 7 lines

If the remote is sending a weird protocol then there are several choices:
  1) implement raw mode
  2) make a Stream-Zap protocol engine (it would be a 14b version of RC-5). Standard RC5 engine will still reject the messages.
  3) throw away your Stream-Zap remotes

I'd vote for #3, but #2 will probably make people happier.

Quoted 8 lines

Hm. Yeah, I know a few people who are quite attached to their Streamzap remotes. I'm not a particularly big fan of it, I only got the thing off ebay to have the hardware so I could work on the driver. :) So yeah, #3 is probably not the best route. But I don't know that I'm a huge fan of #2 either. Another decoder engine just for one quirky remote seems excessive, and there's an option #4:

4) just keep passing data out to lirc by default.

That's a decent idea. Implement the mainstream, standard protocols in the kernel and kick the weird stuff out to LIRC. We can avoid the whole world of raw mode, config files, etc. Let LIRC deal with all that. If the weird stuff gets enough users bring it in-kernel.  Maybe StreamZap will suddenly sell a million units, you never know.

It is easy to implement a StreamZap engine. Just copy the RC5 one. Rename everything and adjust it to require one more bit. You'll have to modify the RC5 to wait for a bit interval (timeout) before sending the data up. If you want to get fancy use a weak symbol in the StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then you can decide to wait the extra bit interval or not.

Quoted 9 lines

Let lircd handle the default remote in this case. If you want to use another remote that actually uses a standard protocol, and want to use in-kernel decoding for that, its just an ir-keytable call away.

For giggles, I may tinker with implementing another decoder engine though, if only to force myself to actually pay more attention to protocol specifics. For the moment, I'm inclined to go ahead with the streamzap port as it is right now, and include either an empty or not-empty, but not-functional key table.

Quoted 4 lines · Jon Smirl

Quoted 3 lines · Jarod Wilson

Quoted 2 lines · Jon Smirl

On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <[email protected]> wrote:

....

Quoted 29 lines

Quoted 14 lines

Quoted 6 lines

Quoted 5 lines

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13. The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5. Did I mention this already? Yes. ;-)

Quoted 7 lines

If the remote is sending a weird protocol then there are several choices:
  1) implement raw mode
  2) make a Stream-Zap protocol engine (it would be a 14b version of RC-5). Standard RC5 engine will still reject the messages.
  3) throw away your Stream-Zap remotes

I'd vote for #3, but #2 will probably make people happier.

Quoted 8 lines

Hm. Yeah, I know a few people who are quite attached to their Streamzap remotes. I'm not a particularly big fan of it, I only got the thing off ebay to have the hardware so I could work on the driver. :) So yeah, #3 is probably not the best route. But I don't know that I'm a huge fan of #2 either. Another decoder engine just for one quirky remote seems excessive, and there's an option #4:

4) just keep passing data out to lirc by default.

That's a decent idea. Implement the mainstream, standard protocols in the kernel and kick the weird stuff out to LIRC. We can avoid the whole world of raw mode, config files, etc. Let LIRC deal with all that. If the weird stuff gets enough users bring it in-kernel.  Maybe StreamZap will suddenly sell a million units, you never know.

Quoted 6 lines

It is easy to implement a StreamZap engine. Just copy the RC5 one. Rename everything and adjust it to require one more bit. You'll have to modify the RC5 to wait for a bit interval (timeout) before sending the data up. If you want to get fancy use a weak symbol in the StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then you can decide to wait the extra bit interval or not.

The other thought I had was to not load the engine by default, and only auto-load it from the streamzap driver itself.

Quoted 9 lines

Quoted 9 lines

Let lircd handle the default remote in this case. If you want to use another remote that actually uses a standard protocol, and want to use in-kernel decoding for that, its just an ir-keytable call away.

For giggles, I may tinker with implementing another decoder engine though, if only to force myself to actually pay more attention to protocol specifics. For the moment, I'm inclined to go ahead with the streamzap port as it is right now, and include either an empty or not-empty, but not-functional key table.

So I spent a while beating on things the past few nights for giggles (and for a sanity break from "vacation" with too many kids...). I ended up doing a rather large amount of somewhat invasive work to the streamzap driver itself, but the end result is functional in-kernel decoding, and lirc userspace decode continues to behave correctly. RFC patch here:

http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch

Core changes to streamzap.c itself:

- had to enable reporting of a long space at the conclusion of each signal (which is what the lirc driver would do w/timeout_enabled set), otherwise I kept having issues with key bounce and/or old data being buffered (i.e., press up, cursor moves up. push down, cursor moves up then down, press left, it moves down, then left, etc.). Still not quite sure what the real problem is there, the lirc userspace decoder has no problems with it either way.

- removed streamzap's internal delay buffer, as the ir-core kfifo seems to provide the necessary signal buffering just fine by itself. Can't see any significant difference in decode performance either in-kernel or via lirc with it removed, anyway. (Christoph, can you perhaps expand a bit on why the delay buffer was originally needed/how to reproduce the problem it was intended to solve? Maybe I'm just not triggering it yet.)

Other fun stuff to note:

- currently, loading up an rc5-sz decoder unconditionally, have considered only auto-loading it from the streamzap driver itself. Its a copy of the rc5 decoder with relatively minor tweaks to deal with the extra bit and resulting slightly different bit layout. Might actually be possible to merge back into the rc5 decoder itself, haven't really looked into that yet (should be entirely doable if there's an easy way to figure out early on if we need to grab 14 bits).

- not sure the decoder is 100% correct, but it does get to the same scancodes as the lirc userspace now (with both a streamzap and mceusb receiver).

Quoted 19 lines

So I spent a while beating on things the past few nights for giggles (and for a sanity break from "vacation" with too many kids...). I ended up doing a rather large amount of somewhat invasive work to the streamzap driver itself, but the end result is functional in-kernel decoding, and lirc userspace decode continues to behave correctly. RFC patch here:

http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch

Core changes to streamzap.c itself:

- had to enable reporting of a long space at the conclusion of each signal (which is what the lirc driver would do w/timeout_enabled set), otherwise I kept having issues with key bounce and/or old data being buffered (i.e., press up, cursor moves up. push down, cursor moves up then down, press left, it moves down, then left, etc.). Still not quite sure what the real problem is there, the lirc userspace decoder has no problems with it either way.

Quoted 7 lines

- removed streamzap's internal delay buffer, as the ir-core kfifo seems to provide the necessary signal buffering just fine by itself. Can't see any significant difference in decode performance either in-kernel or via lirc with it removed, anyway. (Christoph, can you perhaps expand a bit on why the delay buffer was originally needed/how to reproduce the problem it was intended to solve? Maybe I'm just not triggering it yet.)

Should be fine. Current lircd with timeout support shouldn't have a problem with that anymore. I was already thinking of suggesting to remove the delay buffer.

Quoted 10 lines

Other fun stuff to note:

- currently, loading up an rc5-sz decoder unconditionally, have considered only auto-loading it from the streamzap driver itself. Its a copy of the rc5 decoder with relatively minor tweaks to deal with the extra bit and resulting slightly different bit layout. Might actually be possible to merge back into the rc5 decoder itself, haven't really looked into that yet (should be entirely doable if there's an easy way to figure out early on if we need to grab 14 bits).

There is no way until you see the 14th bit.

On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus <[email protected]> wrote:
...

Quoted 27 lines

Quoted 19 lines

So I spent a while beating on things the past few nights for giggles (and for a sanity break from "vacation" with too many kids...). I ended up doing a rather large amount of somewhat invasive work to the streamzap driver itself, but the end result is functional in-kernel decoding, and lirc userspace decode continues to behave correctly. RFC patch here:

http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch

Core changes to streamzap.c itself:

- had to enable reporting of a long space at the conclusion of each signal (which is what the lirc driver would do w/timeout_enabled set), otherwise I kept having issues with key bounce and/or old data being buffered (i.e., press up, cursor moves up. push down, cursor moves up then down, press left, it moves down, then left, etc.). Still not quite sure what the real problem is there, the lirc userspace decoder has no problems with it either way.

Quoted 7 lines

- removed streamzap's internal delay buffer, as the ir-core kfifo seems to provide the necessary signal buffering just fine by itself. Can't see any significant difference in decode performance either in-kernel or via lirc with it removed, anyway. (Christoph, can you perhaps expand a bit on why the delay buffer was originally needed/how to reproduce the problem it was intended to solve? Maybe I'm just not triggering it yet.)

Quoted 3 lines

Should be fine. Current lircd with timeout support shouldn't have a problem with that anymore. I was already thinking of suggesting to remove the delay buffer.

Cool, sounds like a plan then, I'll go ahead with it.

Quoted 11 lines

Quoted 10 lines

Other fun stuff to note:

- currently, loading up an rc5-sz decoder unconditionally, have considered only auto-loading it from the streamzap driver itself. Its a copy of the rc5 decoder with relatively minor tweaks to deal with the extra bit and resulting slightly different bit layout. Might actually be possible to merge back into the rc5 decoder itself, haven't really looked into that yet (should be entirely doable if there's an easy way to figure out early on if we need to grab 14 bits).

Quoted 1 line

There is no way until you see the 14th bit.

Hm. Was afraid of that. I gave it a shot to see if I could make that work, pretty shaky results. About 2/3 of the keys get decoded as 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't match anything in the keytable (and often duplicate one another). So it looks like at least for the time being, a separate parallel decoder is the way to go. I'm thinking that I like the approach of only explicitly loading it from the streamzap driver though.

Quoted 48 lines · Jarod Wilson

On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus <[email protected]> wrote:
...

Quoted 27 lines

Quoted 19 lines

So I spent a while beating on things the past few nights for giggles (and for a sanity break from "vacation" with too many kids...). I ended up doing a rather large amount of somewhat invasive work to the streamzap driver itself, but the end result is functional in-kernel decoding, and lirc userspace decode continues to behave correctly. RFC patch here:

http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch

Core changes to streamzap.c itself:

- had to enable reporting of a long space at the conclusion of each signal (which is what the lirc driver would do w/timeout_enabled set), otherwise I kept having issues with key bounce and/or old data being buffered (i.e., press up, cursor moves up. push down, cursor moves up then down, press left, it moves down, then left, etc.). Still not quite sure what the real problem is there, the lirc userspace decoder has no problems with it either way.

Quoted 7 lines

- removed streamzap's internal delay buffer, as the ir-core kfifo seems to provide the necessary signal buffering just fine by itself. Can't see any significant difference in decode performance either in-kernel or via lirc with it removed, anyway. (Christoph, can you perhaps expand a bit on why the delay buffer was originally needed/how to reproduce the problem it was intended to solve? Maybe I'm just not triggering it yet.)

Quoted 3 lines

Should be fine. Current lircd with timeout support shouldn't have a problem with that anymore. I was already thinking of suggesting to remove the delay buffer.

Cool, sounds like a plan then, I'll go ahead with it.

Quoted 11 lines

Quoted 10 lines

Other fun stuff to note:

- currently, loading up an rc5-sz decoder unconditionally, have considered only auto-loading it from the streamzap driver itself. Its a copy of the rc5 decoder with relatively minor tweaks to deal with the extra bit and resulting slightly different bit layout. Might actually be possible to merge back into the rc5 decoder itself, haven't really looked into that yet (should be entirely doable if there's an easy way to figure out early on if we need to grab 14 bits).

Quoted 1 line

There is no way until you see the 14th bit.

Quoted 7 lines

Hm. Was afraid of that. I gave it a shot to see if I could make that work, pretty shaky results. About 2/3 of the keys get decoded as 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't match anything in the keytable (and often duplicate one another). So it looks like at least for the time being, a separate parallel decoder is the way to go. I'm thinking that I like the approach of only explicitly loading it from the streamzap driver though.

Just one minor nitpick.
You could 'use' the original RC5 decoder, but add a knob to it to make it accept 15 bits instead of 14.
However, this will require some interface changes.

Quoted 4 lines

Just one minor nitpick.
You could 'use' the original RC5 decoder, but add a knob to it to make it accept 15 bits instead of 14.
However, this will require some interface changes.

Well, I think that still falls down if someone, for some reason, wants to use both an old RC5 remote and the Streamzap remote at the same time. I think a parallel decoder is probably the best situation for the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded simultaneously.

Em 16-08-2010 21:14, Jarod Wilson escreveu:

Quoted 10 lines

Quoted 4 lines

Just one minor nitpick.
You could 'use' the original RC5 decoder, but add a knob to it to make it accept 15 bits instead of 14.
However, this will require some interface changes.

Well, I think that still falls down if someone, for some reason, wants to use both an old RC5 remote and the Streamzap remote at the same time. I think a parallel decoder is probably the best situation for the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded simultaneously.

One option could be to change rc5 decoder to work with 3 different modes, controlled by a sysfs node:
1) just 14 bits code;
2) just 15 bits code;
3) both 14 and 15 bits code.

For (3), it will need a timeout logic for a short period (like 2T), for the 15th bit. If nothing happens, it will assume it is 14 bits, producing a code and resetting the finite-state machine.

By default, it would be working on 14-bits mode for normal RC decoders, and on 15-bits mode for Streamzap.

Yet, IMHO, the better is to commit what you have currently. Just my 2 cents.

Hi!

Jon Smirl "[email protected]" wrote:
[...]

Quoted 20 lines

Quoted 4 lines

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly decode in-kernel for the life of me. I got lirc_streamzap 99% of the way ported over the weekend, but this remote just won't decode correctly w/the in-kernel RC5 decoder.

Manchester encoding may need a decoder that waits to get 2-3 edge changes before deciding what the first bit. As you decode the output is always a couple bits behind the current input data.

You can build of a table of states
L0 S1 S0 L1 - emit a 1, move forward an edge
S0 S1 L0 L1 - emit a 0, move forward an edge

By doing it that way you don't have to initially figure out the bit clock.

The current decoder code may not be properly tracking the leading zero. In Manchester encoding it is illegal for a bit to be 11 or 00. They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is off by 1/2 a bit cycle.

Quoted 2 lines

Did you note the comment that Extended RC-5 has only a single start bit instead of two?

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13. The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5. Did I mention this already? Yes. ;-)

Quoted 22 lines · Christoph Bartelmus

Hi Jon,

Quoted 10 lines · Jon Smirl

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way.  A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%).  The crystals used in electronics are accurate to 0.0001%+.

Quoted 8 lines

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz.. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error and caused the JVC code to be misclassified as NEC.

I think he said lirc was misclassifying it too. So we both did the same thing.

Hi Jon,

Quoted 39 lines · Jon Smirl

Quoted 22 lines · Christoph Bartelmus

Hi Jon,

Quoted 10 lines · Jon Smirl

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way.  A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%).  The crystals used in electronics are accurate to 0.0001%+.

Quoted 8 lines

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz.. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error and caused the JVC code to be misclassified as NEC.

Quoted 2 lines

I think he said lirc was misclassifying it too. So we both did the same thing.

No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse JVC with NEC signals?

LIRC will work if there is a 4% or 40% or 400% error. Because irrecord generates the config file using your receiver it will compensate for any

timing error. It will work with pulses cut down to 50 us like IrDA hardware does and it will work when half of the bits are swallowed like the IgorPlug USB receiver does.

But of course the driver should try to generate timings as accurate as possible.

Christoph

Quoted 42 lines · Christoph Bartelmus

Hi Jon,

Quoted 39 lines · Jon Smirl

Quoted 22 lines · Christoph Bartelmus

Hi Jon,

Quoted 10 lines · Jon Smirl

Quoted 8 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way.  A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%).  The crystals used in electronics are accurate to 0.0001%+.

Quoted 8 lines

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz.. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error and caused the JVC code to be misclassified as NEC.

Quoted 8 lines

Quoted 2 lines

I think he said lirc was misclassifying it too. So we both did the same thing.

No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse JVC with NEC signals?

LIRC will work if there is a 4% or 40% or 400% error. Because irrecord generates the config file using your receiver it will compensate for any

At the end of the process we can build a record and match raw mode if we have to.

Quoted 3 lines

timing error. It will work with pulses cut down to 50 us like IrDA hardware does and it will work when half of the bits are swallowed like the IgorPlug USB receiver does.

The code for fixing IrDA and IgorPLug should live inside their low level device drivers.  The characteristics of the errors produced by this hardware are known so a fix can be written to compensate.  The IgorPlug people might find it easier to fix their firmware. You don't have to get the timing exactly right for the protocol engines to work, you just need to get the big systematic errors out.

Before doing raw the low level IR drivers should be fixed to provide the most accurate data possible. I don't think it is good design for a low level driver to be injecting systematic errors and then have the next layer of code remove them.  The source of the systematic errors should be characterized and fixed in the low level driver. That also allows the fixed to be constrained to fixing data from only a single receiver type.

I have been burnt twice in the past from fixing errors in a low level driver higher in the stack. I have learned the hard way that it is a bad thing to do. As the fixes accumulate in the higher layers you will reach a point where they conflict and no solution is possible. Bugs in the low level drivers need to be fixed in that driver.

Show me a case that can't be fixed in the low level driver and we can explore the options.

Quoted 6 lines

But of course the driver should try to generate timings as accurate as possible.

Christoph

--
Jon Smirl
[email protected]

Quoted 47 lines · Christoph Bartelmus

Hi Jon,

Quoted 43 lines · Jon Smirl

Quoted 23 lines · Christoph Bartelmus

Hi Jon,

Quoted 11 lines · Jon Smirl

Quoted 9 lines · Andy Walls

I think you won't be able to fix the problem conclusively either way. A lot of how the chip's clocks should be programmed depends on how the GPIOs are used and what crystal is used.

I suspect many designers will use some reference design layout from ENE, but it won't be good in every case.  The wire-up of the ENE of various motherboards is likely something you'll have to live with as unknowns.

Quoted 8 lines

Quoted 3 lines

This is a case where looser tolerances in the in kernel decoders could reduce this driver's complexity and/or get rid of arbitrary fudge factors in the driver.

The tolerances are as loose as they can be. The NEC protocol uses pulses that are 4% longer than JVC. The decoders allow errors up to 2% (50% of 4%).  The crystals used in electronics are accurate to 0.0001%+.

Quoted 9 lines

But the standard IR receivers are far from being accurate enough to allow tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of 30% / 100 us and even this is not enough sometimes.

For the NEC protocol one signal consists of 22 individual pulses at 38kHz.. If the receiver just misses one pulse, you already have an error of 1/22

Quoted 1 line

4%.

There are different types of errors. The decoders can take large variations in bit times. The problem is with cumulative errors. In this case the error had accumulated up to 450us in the lead pulse. That's just too big of an error and caused the JVC code to be misclassified as NEC.

I think he said lirc was misclassifying it too. So we both did the same thing.