Author Topic: GC100 Pronto Code  (Read 1689 times)

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 5812
  • Karma: +249/-69
  • "Less is more"
Re: GC100 Pronto Code
« Reply #15 on: June 19, 2017, 06:59:20 am »
Wondering if you can implement the above mod before doing a new release?

Version 2017.06.19 in the development branch implements this.
Please tell me it works!

3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 4x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 829
  • Karma: +57/-8
Re: GC100 Pronto Code
« Reply #16 on: July 04, 2017, 08:49:51 pm »
It works fine.

I notice that in Vera, they round their calculations to the nearest thousand Hz. Personally I think it's best to be precise, by using the calculation without any rounding (as you have done in openLuup), as rounding may compromise the associated bit mark/space values. But for the record, here are some sample values that Vera produces:

Code: [Select]
2nd word & frequency calculated by Vera:

0070  37,000 Hz
006F  37,000 Hz
006D  38,000 Hz
006E  38,000 Hz
006D  38,000 Hz
006C  38,000 Hz
006B  39,000 Hz
006A  39,000 Hz
0069  39,000 Hz
0068  40,000 Hz
0067  40,000 Hz
0066  41,000 Hz
0065  41,000 Hz
0064  41,000 Hz
0063  42,000 Hz
0060  43,000 Hz
005F  44,000 Hz
« Last Edit: July 04, 2017, 08:51:22 pm by a-lurker »

Offline Fryswatter

  • Full Member
  • ***
  • Posts: 116
  • Karma: +1/-0
Re: GC100 Pronto Code
« Reply #17 on: January 15, 2018, 06:20:49 pm »
The second word is how many times to repeat the IR code and the third word is an offset into the code that bypasses the preamble of the IR code for those IR codes that use them (not all work this way). This preamble is the IR code preamble and is not to be confused with the GC100 preamble. So the GC100 would generate: IR preamble, IR command, IR command, etc. The third word is only applicable, if the repeat is set to higher than one.

I have always avoided using the GC100 repeat functionality, as you have no control of the dwell time between repeats. As the GC100 allows full control of the mark and space periods, it's easier to just send one command to the GC100 that:  describes your IR code, then describes a dwell period and then your IR code again; all concatenated together to make one big code that contains the repeated IR codes.

Some devices actually require an IR code to be repeated three times with a certain period before they are recognised. Variations on the theme are volume up commands; that use an arbitrary repeat (ie the user is say;  continually depressing the volume up command button) with a relatively long delay between codes being required.

The original Luup routine forced the repeat to two. That is a fundamentally flawed approach and can cause havoc if the IR command is a toggle; like on/off.

In my experience, it's best not to use the GC100 repeat at all. I wrote some Lua code to create any repeated commands I needed, allowing full control over how they were timed. These concatenated codes are then sent as one long code by the GC100.

Other examples are aircons: where the codes sent are very complex; consisting of multiple groups of information. Using any built in repeat command (can) completely stuffs up any attempt to control them.

I do like the fact though that with that pulse train you can, for example, do a volume jump up/down. But you are right it is a flawed design. ;)