Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New device - iVac Pro remote control #3034

Closed
gcormier opened this issue Aug 15, 2024 · 8 comments
Closed

New device - iVac Pro remote control #3034

gcormier opened this issue Aug 15, 2024 · 8 comments

Comments

@gcormier
Copy link
Contributor

gcormier commented Aug 15, 2024

Pretty basic device using OOK.

FCC : YCH-IVACPRO
433MHz
https://www.ivacswitch.com/wp-content/uploads/2024/06/iVAC-Remote-User-Guide-ENG-FR-SP-14789-004-warning.pdf

image

First 2 dip switches are "System Address"
Next 3 dip switches are a "Tool Address"

https://github.com/gcormier/rtl_433_tests/tree/ivacpro

Are these enough captures to figure out what's going on?

@ProfBoc75
Copy link
Collaborator

ProfBoc75 commented Aug 16, 2024

Hi @gcormier

First, missing the file g001 and g003, were in your readme file but not uploaded, could help to confirm my assumption regarding system address.

My findings:

  • Modulation OOK_PWM, s=420, l=856, r=2000
  • Repeated message of 13 bits.

Data Layout:

Bit position 1234 5678 1234 5678
             IIII IISS CTTT P000
  • I:{6} Possible ID
  • S:{2} Possible System Address, reverse and invert (S2 S1), to be confirmed with more samples, this is my assumption from Tool Address approach.
  • C:{1} Command, invert, 0 = On, 1 = OFF
  • T:{3} Tool Address, reverse and invert (S5 S4 S3)
  • P:{1} Parity of previous bits
  • 0:{3} Always zeros as message is 13 bits

From this you can create a configuration file to decode the signal, but parity (like CRC/CHECKSUM) is not handle by conf/flex decoder.

Try this:

rtl_433 -X 'n=iVacPro,m=OOK_PWM,s=420,l=856,r=2000,bits=13,unique,get=id:@0:{6}:%d,get=CMD:@8:{1}:[0:ON 1:OFF],get=SYSTEM_ADDRESS:@6:{2}:[0:D_11 1:B_10 2:C_01 3:A_00],get=TOOL_ADDRESS:@9:{3}:[0:7_111 1:6_011 2:5_101 3:4_001 4:3_110 5:2_010 6:1_100 7:8_000],get=Parity:@12:{1}:%d'

In result you have the system address letter follow by the dip position S1 S2, the tool address number follow by the dip position S3 S4 S5, the CMD ON/OFF, the sensor ID.

@gcormier
Copy link
Contributor Author

Awesome, thanks! I've added the 2 missing files (oops!) - I'm heading out for the day but I'll give it a shot later!

I've also got the hex firmware extracted, so I can run it in Ghidra and see if it's possible to figure out the checksum formula.

@ProfBoc75
Copy link
Collaborator

ProfBoc75 commented Aug 18, 2024

Hi @gcormier

Thanks to your 2 missing files, which confirmed my assumption, I can share a little update:

rtl_433 -X 'n=iVacPro,m=OOK_PWM,s=420,l=856,r=2000,bits=13,unique,get=id:@0:{6}:%d,get=CMD:@8:{1}:[0:ON 1:OFF],get=SYSTEM_ADDRESS:@6:{2}:[0:D_11 1:C_01 2:B_10 3:A_00],get=TOOL_ADDRESS:@9:{3}:[0:7_111 1:6_011 2:5_101 3:4_001 4:3_110 5:2_010 6:1_100 7:8_000],get=Parity:@12:{1}:%d'

If you want to replay your cu8 file, just add name at the end of the above command.

Notice that the checksum formula is one bit parity ( 0 or 1) of the 12 first bits. I show the bit parity value from the above command, the third bit of the message, but it's not verified. A decoder is needed for that.

Edit: I also notice that the message is repeated 24 times, for a total duration of 3.052 seconds and because the gap between messages is too high, 127 ms, rtl_433 can't remove duplicated values with the flex option unique.

@gcormier
Copy link
Contributor Author

Thanks so much! Since it can be decoded with a flex decoder, is there something I can do to contribute to rtl_433 to recognize this device? Or does it just remain as a known device using a flex decoder?

@ProfBoc75
Copy link
Collaborator

@gcormier

Thanks so much! Since it can be decoded with a flex decoder, is there something I can do to contribute to rtl_433 to recognize this device? Or does it just remain as a known device using a flex decoder?

You or me can create a conf file based on the flex decoder and pull a request to add it to rtl_433.

If you don't know how to proceed, you have samples in conf folder, and it's mostly based on the flex options.

gcormier added a commit to gcormier/rtl_433 that referenced this issue Sep 7, 2024
@gcormier
Copy link
Contributor Author

gcormier commented Jan 11, 2025

I'm trying to make a transmitter now and what's interested is that the pulses aren't exactly fixed as neatly as in the decoder for rtl_433 :( I'm not sure what's going on but it's been a great tool to try and figure it out.

image

@gcormier
Copy link
Contributor Author

Got it. The first 6 bits can just be fixed with their own weirdness, the rest are good.

image

@gcormier
Copy link
Contributor Author

Hmm just realized the low values for system address are also weirdly long.

Am I misunderstanding how this signal works? Why are the two 1's that occur ~1293uS, whereas the subsequent 1's are ~900uS?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants