Mid-Frame Bursts

[Mog]

So, I am now looking at developing another upgrade, this time for a Holdan Scart switching box

I was pretty confident that I could do this one, after all the stuff I learnt
looking at the Panasonic PT-AE500 Projector

BUT, of couse there has to be a catch...

This device makes use of Mid-Frame bursts.

I can see that the code generated for the S3C8+ is different depending on whether Mid-Frame bursts
are chosen or not, but in the case of the P8/740, the code is the same.

Would I be correct in thinking that the IR engine on the S3C8+ based remotes does support Mid-Frame bursts,
and that the P8/740 does not?

Or maybe just Protocol-Builder doesn't support it...

[jon_armstrong]

I'll let the experts who wrote PB answer that question. But as a practical matter you can define for example a One as +500,-000 and a Zero as +000,-500. Assuming the real One is +500,-1500 and Zero is +500,-500, then a One is "1000" and a Zero is 10.

There is however a limit of 72 bits in the SC380 version (and less from what Mike said in the 740). So that gimmick only works with short sequences.

If you are using an extender and the gap is long enough you can do it with a macro. I think it takes something like 25 mS between commands using the extenders that drastically speed up macros.

Finally, some commands may execute with only the first half if only one or two bits change between the two sequences it could be a make and break bit (sends one command when pressed another when released)

Come to think of it Rob, how about a sub-forum for PB. It would be much easier finding this stuff later and any beginner reading this will probably return his JP1 cable and remote and get a Harmony

[The Robman]

Come to think of it Rob, how about a sub-forum for PB. It would be much easier finding this stuff later and any beginner reading this will probably return his JP1 cable and remote and get a Harmony

I certainly agree that this thread should be moved out of the beginners forum at least (and I'll take care of that). As to whether we need to create a new forum, I've started a poll to see what the consensus is. I'm OK with it as I always use the "new posts since your last visit" option, but I would guess that people who manually read through each forum might not be so keen.

[mr_d_p_gumby]

Would I be correct in thinking that the IR engine on the S3C8+ based remotes does support Mid-Frame bursts, and that the P8/740 does not?
Or maybe just Protocol-Builder doesn't support it...

I'm not aware of any way the P8/740 IR engine can do a mid-frame burst, but that doesn't mean it can't. It might just mean we don't know how to make it do it. In any case, PB only knows what we know. As the PB readme states, support for the P8/740 & 6805-C9 IR engines is incomplete. Most of the commonly used items have been investigated, but there are still a few items that need further research, and you've just discovered one of them.

[jon_armstrong]

BTW, the mid frame burst does work with the S3C80 remotes, BUT, it is either the lead in OR the mid frame burst.

[Mog]

Assuming the real One is +500,-1500 and Zero is +500,-500, then a One is "1000" and a Zero is 10.

That's a nice bit of lateral thinking

But surely the length of the One needs to be the same as the length of the Zero?

[jon_armstrong]

But surely the length of the One needs to be the same as the length of the Zero?

I'm not sure quite what you mean. That technique does work but you do have to think through things like frame length particulaly if it has a lead out on pulse. You may have to add extra "0" 's at the end to get the same number of bits for every command. You can also adjust the final off time such that you get a constant frame length.

But you can have zero on or off times and you can transmit a "Zero" backwards (usually for bi-phase) but that gives more flexibility

If you post the raw signals, I can be more specific. The easiest way is to post your EEPROM image of the learned signals to the diagnosis area in the old JP1 Yahoo site. And post a link, please.

[Mog]

Example IR file from my Kameleon here
CD CH+ and CH- are two examples of keys with mid-frame bursts

What I meant was that if One is 1000 and Zero is 10, then an 8 bit byte
equal to zero would be 32 bits long and an 8 bit byte equal to one would be 16 bits long

Obviously different buttons will have different numbers of ones and zeros
in them, so then not all buttons would generate the same total byte count...

[jon_armstrong]

Actually, the Proton protocol decodes look correct and I'm sure they would work. But for the sake of discussion, in this case I would make:

One=+526-532 and Zero=+0,-532

There are four commands CD ch+/- and vol+/-

If you make those substitutions you get 54 data bits for the first two and 56 data bits for the latter. (I took care of the lead out On time by adding a 1 to the end of the databits and is included in the bit count). Then add two extra zero's to the first two all now have 56 bits and are as follows:

88 88 8A A0 11 55 54 c+
88 88 8A A0 15 15 54 c-
88 88 8A A0 11 15 55 v+
88 88 8A A0 14 45 55 v-

Pick four 8-bit bytes of fixed data and three 8-bit bytes of variable data.

You select as a lead in +8440,-4258 and -25000 as lead-out style[0]

And I think you will come very close.

I use Excel to make the substitution of all those bits and I'll post my spreadsheet if you would like to see it. Obviously in practice, you would save many bytes of memory and use the built in Proton protocol.

But for a few commands of a obscure protocol where this is no built-in protocol, this method is surprisingly powerful.

(BTW, sometimes you have to use"reverse the bits" for zero to get this to work correctly. I can't remember whether that is a zero defined as +500,-000 or +000,-500 but one of them reqires that. Needless to say, I always test these things.)

[johnsfine]

(BTW, sometimes you have to use"reverse the bits" for zero to get this to work correctly. I can't remember whether that is a zero defined as +500,-000 or +000,-500 but one of them reqires that. Needless to say, I always test these things.)

I'm nearly certain that reversing a zero defined as +000,-XYZ would have no effect.

Reversing a zero defined as +XYZ,-000 has a very subtle effect.

The remote has special logic to suppress the phase glitch that occurs when two + durations occur in sequence. But for some reason it doesn't always enable that logic when it would be desirable. That's a detail I don't fully understand. I think there is a way to force that feature on without reversing the zero bit (but I'm unclear on details and I don't think PB supports it). But I know that reversing the zero bit does force that feature on.

Without the feature to prevent phase glitches and with two + durations in a row, you MIGHT have a phase glitch. Whether you do or not depends on an interation between the frequency and the durations, which I don't understand to fine enough granularity to be able to compute whether a significant phase glitch will occur.

If you have a phase glitch, you MIGHT have a problem because of it. Typical devices don't care about phase glitches, so usually the protocol will work anyway. Learning remotes, especially the JP1 learning remotes are particularly picky about phase glitches, so the usual symptom is that the signal works just fine but you can't use relearning and decoding the signal as a method of checking it.

[The Robman]

Actually, the Proton protocol decodes look correct and I'm sure they would work.

I was trying to remember what official protocol uses a mid-burst and of course, it's Proton. So, I took a look at the assembler code used in both the S3C8 and 740 versions of the UEI executor and it confirms that while the S3C8 remotes can do this using the engine, the 740 remotes need to handle it manually.

Here's the 2 versions disassembled...

Proton: $005C (S3C8+):

Code: Select all

FF00: 43 8C       DB 43H, 8CH
FF02: 11          DB 11H

FF03: 8B 16       JR FF1BH

FF05: C5 45       DB C5H, 45H
FF07: 08 08       DB 08H, 08H
FF09: 01 09       DW 0109H
FF0B: 00 F5       DW 00F5H
FF0D: 01 09       DW 0109H
FF0F: 03 07       DW 0307H
FF11: 7B 8E       DW 7B8EH
FF13: 10 7C       DW 107CH
FF15: 08 2A       DW 082AH
FF17: 00 00       DW 0000H
FF19: 00 09       DW 0009H

FF1B: 8D 01 61    JP 0161H

Proton: $005C (740):

Code: Select all

0132: 0B 1A       DB $0B, $1A
0134: 11 DB       $11

0135: 80 0F       BRA $0146

0137: C0 78 14 08 DB $C0, $78, $14, $08
      08 01 9C 02 DB $08, $01, $9C, $02
      FB 04 6C 40 DB $FB, $04, $6C, $40
      06 6F 02    DB $40, $06, $6F, $02

0146: BF 3C       CLB 5,$3C
0148: AF 3E       SEB 5,$3E
014A: EF 28       SEB 7,$28
014C: 3C D1 22    LDM #$D1,$22
014F: 3C 3D 23    LDM #$3D,$23
0152: FF 28       CLB 7,$28
0154: 3C 00 5B    LDM #$00,$5B
0157: 3C 78 7F    LDM #$78,$7F
015A: 22 00       JSR \$FF00
015C: E6 5B       INC $5B
015E: 3C 60 7F    LDM #$60,$7F
0161: 22 00       JSR \$FF00
0163: 22 06       JSR \$FF06
0165: A7 3E FD    BBS 5,$3E,$0165
0168: 90 DC       BCC $0146
016A: 60          RTS

[mr_d_p_gumby]

The IR engines in both the S3C8 and M6805-RC16/18 remotes support the mid-frame burst. Note how the Proton protocol, in both these cases, uses a special vector to call the IR engine to activate the mid-frame burst: $0161 for the S3C8 and $01C4 for the M6805-RC16/18. PB uses this vector for the M6805-RC16/18, but sets the flag in code and uses the standard vector for the S3C8. (Since I did not create the S3C8 part of PB, you'd have to ask John if there's a specific reason the special vector was not used.)

Proton: $005C ( M6805-RC16/18 )

Code: Select all

0100 11 24           DB  $11,$24     ;37.7 kHz 32%
0102 11              DB  $11         ;1 dev, 1 cmd
0103 20 14           BRA L0119	
0105 C5              DB  $C5         ;pf0: 11000101=1-dev,1-cmd,dev-cmd,OffAsTotal
0106 45              DB  $45         ;pf1: 01000101=RptHeld,LI-same,1on-LO
0107 08              DB  $08         ;pd00: DevBits1=8
0108 08              DB  $08         ;pd01: CmdBits1=8
0109 00 84 85        DB  $00,$84,$85 ;pd02/03/04: 1-burst on/off=532/532 uS
010C 01 84 8E        DB  $01,$84,$8E ;pd05/06/07: 0-burst on/off=532/1592 uS
010F 3D D1           DW  $3DD1       ;pd08/09: Leadout off=63260 uS
0111 00              DB  $00         ;pd0A: 
0112 84 3D 1F        DB  $84,$3D,$1F ;pd0B/0C/0D: Leadin on/off=8440/4220 uS
0115 04              DB  $04         ;pd0E: DevBits2=4
0116 84              DB  $84         ;pd0F: Repeat=132
0117 1F              DB  $1F         ;pd10: CmdBits2=31
0118 09	           DB  $09         ;pd11: 
0119 CC 01 C4 L0119: JMP $01C4

It does appear as if the P8/740 and M6805-C9 IR engines do not directly support the mid-frame burst without a bunch of added code.

[Mog]

Actually, the Proton protocol decodes look correct and I'm sure they would work.

OK, I'll try and use the Proton protocol - I must admit I was a bit put off
by the fact that there were extra lines in the decode [ Gap-526-1242? ]
and also associated 'OBC' values...

Then add two extra zero's to the first two all now have 56 bits and are as follows:

OK, so I was correct in my thinking - your solution is simply to add zeroes
to pad out the sequence to make them all the same length

Again, thanks all for the excellent explanations 8)

[jon_armstrong]

OK, I'll try and use the Proton protocol - I must admit I was a bit put off by the fact that there were extra lines in the decode [ Gap-526-1242? ] and also associated 'OBC' values...

There are three protocols that DecodeIR.dll (that IR calls for decoding) frequently identifies incorrectly: Gap, AirB, and Async. So if you see a decode for those and something else, the other decodee is more likely to be correct -- particularly if all the commands have the same device number and have different OBC's from each other.

Other that, DecodeIR.dll does an amazingly good job of accurately decoding a large repertoire of protocols.

[Mog]

I have tried using the Proton protocol, and (as expected, I guess)
it produces the required LI, data bits and LO, but no mid-frame pulse

So I decided to try and hand-craft my own protocol, and output the
mid-frame pulse directly.

This works a treat, but now the LI on time and LO off time are both
too short. They both seem to be short by 6649 uSec

This I believe, is because I haven't been able to work out how to
set the 'Lead In On Extend' value

When I tried the basic Proton protocol in PB, it set the LI value of 8415 uSec
by setting $44 (1766 uSec) in pd09 and $02 (6649 uSec) in pd0c which totals 8415 uSec

How can I get a value into pd0c??

I tried this, but it didn't change the values