|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
Mog
Joined: 02 Jun 2004 Posts: 48
|
Posted: Mon Jun 28, 2004 3:33 pm Post subject: Mid-Frame Bursts |
|
|
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... |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Mon Jun 28, 2004 4:26 pm Post subject: |
|
|
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 _________________ -Jon |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21254 Location: Chicago, IL |
Posted: Mon Jun 28, 2004 6:43 pm Post subject: |
|
|
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 |
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 |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Mon Jun 28, 2004 9:01 pm Post subject: Re: Mid-Frame Bursts |
|
|
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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Mon Jun 28, 2004 9:12 pm Post subject: |
|
|
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 |
|
|
Mog
Joined: 02 Jun 2004 Posts: 48
|
Posted: Tue Jun 29, 2004 5:29 am Post subject: |
|
|
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
But surely the length of the One needs to be the same as the length of the Zero? |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Tue Jun 29, 2004 7:49 am Post subject: |
|
|
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 |
|
|
Mog
Joined: 02 Jun 2004 Posts: 48
|
Posted: Tue Jun 29, 2004 11:04 am Post subject: |
|
|
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 |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Tue Jun 29, 2004 12:00 pm Post subject: |
|
|
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 |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Tue Jun 29, 2004 12:40 pm Post subject: |
|
|
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 |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21254 Location: Chicago, IL |
Posted: Tue Jun 29, 2004 1:02 pm Post subject: |
|
|
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 |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Tue Jun 29, 2004 2:40 pm Post subject: |
|
|
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 |
|
|
Mog
Joined: 02 Jun 2004 Posts: 48
|
Posted: Tue Jun 29, 2004 3:35 pm Post subject: |
|
|
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
Again, thanks all for the excellent explanations 8) |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Tue Jun 29, 2004 4:23 pm Post subject: |
|
|
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 |
|
|
Mog
Joined: 02 Jun 2004 Posts: 48
|
Posted: Fri Jul 09, 2004 7:01 pm Post subject: Protocol Builder Question |
|
|
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 |
|
Back to top |
|
|
|
|
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
|