Unsupported protocol: Holtek (e.g. HT-640), also used in Linx remotes

The Holtek encoding is also used in Linx remote products (and rebranded Pentair remotes for spas which are just Linx).

Multiple frequencies:

  • 315 MHz
  • 418 MHz
  • 433.92 MHz

Modulation: ASK (OOK, AM)

Codes: static

https://fcc.io/OJM-CMD-HHLR-XXXA

Datasheet with protocol description: HT640 pdf, HT640 Description, HT640 Datasheet, HT640 view ::: ALLDATASHEET :::

(sorry for the multiple replies but I’m only able to post 2 links per post due to just creating an account)

Manual for linx remote: http://www.linxtechnologies.com/wp/wp-content/uploads/cmd-hhlr-fff.pdf

Also described in an article here (page 56): https://d1.amobbs.com/bbs_upload782111/files_34/ourdev_589456I42A8D.pdf

Recordings (I believe address/code is 0000000000 but I don’t have access to the remote):

Pentair_A_off.sub (8.8 KB)
Pentair_A_on.sub (13.0 KB)

Pentair_B_off.sub (7.7 KB)
Pentair_C_off.sub (7.6 KB)

Pentair_C_on.sub (5.3 KB)
Pentair_Spa_Off.sub (9.0 KB)

ok, but already in the queue … they already sketched enough here, I’m not rubber

accepts, recognizes buttons, it remains to make a transfer and you can vibrate yourself

Excellent, thanks for adding support for that.

waiting for tests on a real device, I have nothing to check

I tested this with the TXE-418-KH2 chip which uses the HT640 internally. It produces slightly different timing, but I believe it’s likely related to the oscillator changing with voltage slightly. I needed to change the values in the decoder slighty:

static const SubGhzBlockConst subghz_protocol_holtek_const = {
    .te_short = 450,
    .te_long = 900,
    .te_delta = 100,
    .min_count_bit_for_found = 40,
};

Instead of the 500,1000 as it was. With that change though I’m able to decode the new raw files and to read the decoded signal directly. Also, the previous raw files I uploaded continue to work.

Test3.sub (30.1 KB)
Test2.sub (27.1 KB)
Test.sub (11.0 KB)

yes you are right, duration 450/900


but in fact, it was not necessary to do this, in 1 of those records that you sent there, the durations were 500/1000, the fastest is due to low battery, but the algorithm is built so that it will collect durations 400…600=500 800… 1200=1000

could you take pictures of the board with the dip switches, or is it better to set them yourself (all off, all on, on 1, on 10, 1,3,5,7,9. 2,4,6,8,10) and append entries, then add even the position of the dip switches

This is with this chip: https://linxtechnologies.com/wp/wp-content/uploads/txe-fff-kh2.pdf

In a test board:

Off here means floating (not driven to ground or vcc). On is driven to ground. No buttons were pressed (all floating). Only the transmit was triggered.

All off:
Raw_signal_1.sub (16.5 KB)

All on:
Raw_signal_2.sub (22.8 KB)

1 on
Raw_signal_3.sub (22.9 KB)

10 on
Raw_signal_4.sub (17.3 KB)

1,3,5,9 on
Raw_signal_5.sub (10.0 KB)

2,4,6,8,10 on
Raw_signal_6.sub (13.4 KB)

These are recording of the buttons with an address of 0000000000. The name of the file maps to the input on the chip between driven to vcc with the rest floating (input 0 → Raw_signal_1, 1 → 2, etc). The chip itself doesn’t have the concept of on/off and just sends all the inputs at once (so really can have multiple “on” at once).

Raw_signal_8.sub (3.7 KB)
Raw_signal_7.sub (3.6 KB)
Raw_signal_6.sub (2.6 KB)
Raw_signal_5.sub (2.5 KB)
Raw_signal_4.sub (2.6 KB)
Raw_signal_3.sub (2.7 KB)
Raw_signal_2.sub (3.7 KB)
Raw_signal_1.sub (2.9 KB)

Good

in theory, dip switches can switch not only to Gnd, but also to Vcc. do you have such records? and as I understand it, the HT-640 can also transmit several simultaneously pressed buttons?

DIP-=> 1 2 3 4 5 6 7 8 9 A	
  0101 10101010101010101010 1010101010101010
  0101 00000010000000000000 1010101010101010
  0101 00101010101010101010 1010101010101010
  0101 10101010101010101000 1010101010101010
  0101 00100010001000100010 1010101010101010
  0101 10001010100010001000 1010101010101010

                    Btn ==>1 2 3 4 5 6 7 8		
0101 00000010000000000000 1110101010101010
0101 00000010000000000000 1011101010101010
0101 00000010000000000000 1010111010101010
0101 00000010000000000000 1010101110101010
0101 00000010000000000000 1010101011101010
0101 00000010000000000000 1010101010111010
0101 00000010000000000000 1010101010101110
0101 00000010000000000000 1010101010101011

I assume that if DIP is connected to VCC, the DIP bits will shift 1 bit to the left. you can at least stick to what flipper writes
the KEY field if DIP is enabled on VCC, as you send me, I will redo the display and by pressing the buttons and DIP multiple timesPreformatted text

I’ll capture version with address driven to vcc in the next day or two, and will capture multiple button presses (combinations of the data line) as well.