Weird import/export issue with this nec1 lirc files

[irplus-remote]

Hi, hope everything is alright, been a long time i did not nag , but i got a small issue now:

The file below imports correctly (there seem to be 64 bits in total not 32 like a regular NEC controller)

After export to irplus (PRONTO) however only 32 bits are exported. Any idea what to do?

PRONTO:
0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 05F7 015B 0057 0016 0E6C

# Please take the time to finish this file as described in
# https://sourceforge.net/p/lirc-remotes/wiki/Checklist/
# and make it available to others by sending it to
# <lirc@bartelmus.de>
#
# This config file was automatically generated
# using lirc-0.10.1(default) on Thu Dec  3 15:44:38 2020
# Command line used: -n -d /dev/lirc1
# Kernel version (uname -r): 5.4.72-v7l+
#
# Remote name (as of config file): xmas1
# Brand of remote device, the thing you hold in your hand:
# Remote device model nr:
# Remote device info url:
# Does remote device has a bundled capture device e. g., a
#     usb dongle? :
# For bundled USB devices: usb vendor id, product id
#     and device string (use dmesg or lsusb):
# Type of device controlled
#     (TV, VCR, Audio, DVD, Satellite, Cable, HTPC, ...) :
# Device(s) controlled by this remote:

begin remote

  name  xmas1
  bits           32
  flags SPACE_ENC
  eps            30
  aeps          100

  header       9225  4414
  one           657  1581
  zero          657   505
  ptrail        658
  repeat       9217  2155
  gap          39312
  repeat_gap   95714
  toggle_bit_mask 0x0
  frequency    38000

      begin codes
          power                    0x00FFA25D 0x5163EE00
          poweroff                 0x00FF22DD 0x5163EE00
          sensor                   0x00FF629D 0x5163EE00
          sensoroff                0x00FF02FD 0x5163EE00
          brightplus               0x00FFE21D 0x5163EE00
          brightdown               0x00FFC23D 0x5163EE00
          imeron                   0x00FFE01F 0x5163EE00
          4h                       0x00FFA857 0x5163EE00
          6h                       0x00FF906F 0x5163EE00
          timeroff                 0x00FF6897 0x5163EE00
          8h                       0x00FF9867 0x5163EE00
          10h                      0x00FFB04F 0x5163EE00
          steady                   0x00FF30CF 0x5163EE00
          wave                     0x00FF18E7 0x5163EE00
          phase                    0x00FF7A85 0x5163EE00
          fadephase                0x00FF10EF 0x5163EE00
          twinkle                  0x00FF38C7 0x5163EE00
          fade                     0x00FF5AA5 0x5163EE00
          twinklbtm                0x00FF42BD 0x5163EE00
          combi                    0x00FF52AD 0x5163EE00
      end codes

end remote

[bengtmartensson]

You have found a Lirc file somehow. Semantically correct as a Lirc file, IrScrutinizer imports it; however, it does not (fully) match any of the known protocols. The first part matches the NEC1 though. So if you are selecting a parametrized export, you get the match, namely NEC1. This is the correct behavior, and not a bug.

If you so desire, you can import as raw, and then export as raw. Personally, I would not trust the Lirc file though...

Lirc is a headless chicken: dead but still running...;-).

[irplus-remote]

I actually did read it via irrecord not found somewhere :) The remote really sends 2 codes one after another.
So i think i should go with RAW. Thanks if you want you can close it. If thats off-spec. Or is there maybe a different NEC version recently? I think they do this because too many devices share the same code as the number of remotes inreases 32bit are not enough to avoid conflicts

[bengtmartensson]

Why are you using irrecord when you have IrScrutinizer? If you are using a /dev/lirc hardware, you can instead read from /dev/lirc in IrScrutinizer.

There is a protocol Pioneer-Mix that is probably what you see here. It has two "NEC-like" payloads. Note that is has another modulation frequency (40kHz) though.

Furthermore, importing as raw probably works, but better is to recapture with IrScutinizer.

[pavluriy]

Is there a way to capture a signal using lirc devices (com port-dcd) in windows environment with irscrutinizer?

[bengtmartensson]

What are "lirc devices ... in windows environment"? Sounds like a contradiction to me...

[pavluriy]

I apologize, I put it wrong. I meant the use of Serial Port Receivers ( https://www.lirc.org/receivers.html ) , like winlirc does. Is it possible to use such a device to capture a signal using irscrutinizer in windows?

[bengtmartensson]

No. I severely doubt that WinLirc can handle it too. On Linux, IrScrutinizer can handle /dev/lirc devices though.

I recommend this.

[pavluriy]

Thank you for your reply and for your wonderful program.

[irplus-remote]

Hi, I was reading this from a headless machine so I used irrecord. I'll try again to install a GUI maybe and re-try