JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Mid-Frame Bursts
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
Mog



Joined: 02 Jun 2004
Posts: 48

                    
PostPosted: Mon Jun 28, 2004 3:33 pm    Post subject: Mid-Frame Bursts Reply with quote

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

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

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...
Back to top
View user's profile Send private message
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Mon Jun 28, 2004 4:26 pm    Post subject: Reply with quote

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 Smile
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Mon Jun 28, 2004 6:43 pm    Post subject: Reply with quote

jon_armstrong wrote:
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 Smile

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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Mon Jun 28, 2004 9:01 pm    Post subject: Re: Mid-Frame Bursts Reply with quote

Mog wrote:
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.
_________________
Mike England
Back to top
View user's profile Send private message
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Mon Jun 28, 2004 9:12 pm    Post subject: Reply with quote

BTW, the mid frame burst does work with the S3C80 remotes, BUT, it is either the lead in OR the mid frame burst.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Mog



Joined: 02 Jun 2004
Posts: 48

                    
PostPosted: Tue Jun 29, 2004 5:29 am    Post subject: Reply with quote

jon_armstrong wrote:
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 Smile

But surely the length of the One needs to be the same as the length of the Zero?
Back to top
View user's profile Send private message
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Tue Jun 29, 2004 7:49 am    Post subject: Reply with quote

Mog wrote:
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.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Mog



Joined: 02 Jun 2004
Posts: 48

                    
PostPosted: Tue Jun 29, 2004 11:04 am    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Tue Jun 29, 2004 12:00 pm    Post subject: Reply with quote

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.)
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Tue Jun 29, 2004 12:40 pm    Post subject: Reply with quote

jon_armstrong wrote:

(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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Jun 29, 2004 1:02 pm    Post subject: Reply with quote

jon_armstrong wrote:
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:
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:
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

_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Tue Jun 29, 2004 2:40 pm    Post subject: Reply with quote

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:
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.
_________________
Mike England
Back to top
View user's profile Send private message
Mog



Joined: 02 Jun 2004
Posts: 48

                    
PostPosted: Tue Jun 29, 2004 3:35 pm    Post subject: Reply with quote

jon_armstrong wrote:
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...
jon_armstrong wrote:
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 Smile

Again, thanks all for the excellent explanations 8)
Back to top
View user's profile Send private message
jon_armstrong
Expert


Joined: 03 Aug 2003
Posts: 1238
Location: R.I.P. 3/25/2005

                    
PostPosted: Tue Jun 29, 2004 4:23 pm    Post subject: Reply with quote

Mog wrote:
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.
_________________
-Jon
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Mog



Joined: 02 Jun 2004
Posts: 48

                    
PostPosted: Fri Jul 09, 2004 7:01 pm    Post subject: Protocol Builder Question Reply with quote

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 Sad

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 Surprised
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control