|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
Guinness
Joined: 21 Jan 2004 Posts: 5 Location: Arlington, VA |
Posted: Wed Jan 21, 2004 2:16 pm Post subject: Re: old Yahoo thread on Sunfire protocol |
|
|
I am attempting to build a Sunfire protocol, but I am very new to all of this. I have read most of the JP1 documents, and I think I understand most of it. However, I don't see how you came up with "3 device bits" from looking at the Sunfire Pronto document).
I see that there are 12 "data bits", but there is no distinction made between device and command bits. Also, your 3 device plus 8 command bits only makes 11 bits... what about that 12th bit?
This is my maiden voyage into JP1, so I may have more questions as I go--but I am a “hacker” by nature and an engineer by profession, so hopefully my questions won't be too intolerable...
Thanks,
David
--- In jp1@yahoogroups.com, "johnsfine" <johnfine@a...> wrote:
>
> I looked at their PDF (it was easier than asking questions).
>
> It's very clearly documented and simple, but I've never seen that
> protocol before. I think they invented it. So I really doubt that
> you'd find it as an existing UEI protocol.
>
> It's very easy to recreate in the PB spreadsheet:
>
> 38Khz
> Lead In = 9000 -4500
> Zero = 560 -560
> One = 1680 -560
> LeadOut = -18540
>
> 3 device bits
> 8 command bits
>
> Overall structure is dev cmd !dev !cmd
>
> Once it's defined in PB, you need to put in either in KM or in
> protocols.ini for RM. It needs "msb" format for the 8-bit commands,
> and the 3 bit device is always 0.
>
> --- In jp1@yahoogroups.com, "Gary Sabo" <sabogj@y...> wrote:
>
> > I have a sunfire theater grand receiver and sunfire lists all of
> > their codes for the Pronto remote on their website. How, if possible
> > would I translate this code to work with my 8811 remote....or how
> > can I get this code into either remote master or keymaster? _________________ "The only people who inherit anything by right of birth are congenital idiots" -- Asimov |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Wed Jan 21, 2004 3:20 pm Post subject: Re: old Yahoo thread on Sunfire protocol |
|
|
Guinness wrote: | I am attempting to build a Sunfire protocol, but I am very new to all of this. I have read most of the JP1 documents, and I think I understand most of it. However, I don't see how you came up with "3 device bits" from looking at the Sunfire Pronto document |
Sorry. I didn't mean to imply I got THAT from the Sunfire document. That was part of a suggestion on how to use PB rather than an analysis of the signal itself.
Having more than 8 command bits is inconvenient in JP1. It's possible to do if there is a real need, but it's worth avoiding if easy to avoid.
In the pdf it listed all commands and only the bottom 8 bits ever changed. The top bits are always zero. So by pretending the top bits are device bits, the protocol is simpler to build.
Guinness wrote: |
Also, your 3 device plus 8 command bits only makes 11 bits... what about that 12th bit? |
I can't remember what I had in mind, whether I just missed that detail or forgot to mention some work around or had some basis for thinking it was an error in the PDF or what. Looking again at the PDF, I see something slightly tricky.
They show 12 bits of "data" followed by 11 bits of "!data". I believe the !data is a bit for bit inverse of the data, so it must be the same length. That means (if the PDF is correct) you'd need to somehow get one more bit included between the lead-in and the data and then use 11 bits of data.
There is a way in PB to insert one extra burst, but I don't see that I told you to do that. So I'm not sure what I was thinking. |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Wed Jan 21, 2004 3:28 pm Post subject: |
|
|
I just consulted another source (the decode by my DecodeIr.DLL program of a sunfire ccf). The 11 is just wrong.
It should have been 4 device bits and 8 command bits.
They really have 12 bits of data and 12 (not 11) bits of !data, but they didn't know how to document the fact that the last !data bit is merged with the Leadout, so Lead_in plus 12 data plus 12 !data plus lead out is 25 bursts, not the 26 you might expect.
In PB it is quite simple to specify that lead out merges with the last bit. In fact it is the default (lead out style 0). |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Wed Jan 21, 2004 3:43 pm Post subject: |
|
|
John,
I just decoded the document and it looks like:
{38K,562, MSB}<1,-1|3,-1>(8,-4,D:6,F:6,~D:6,~F:6,-33)+
those match their decimal description. _________________ -Jon |
|
Back to top |
|
|
Guinness
Joined: 21 Jan 2004 Posts: 5 Location: Arlington, VA |
Posted: Wed Jan 21, 2004 3:55 pm Post subject: |
|
|
Yeah, I figured out the part about merging the last with the lead out to get 12 bits of !data+lead-out. I haven't gotten far enough in my understanding yet to make much sense out of jon_armstrong's decoding, but I'll work on it after I get home (from my *real* job) today and hopefully figure it out.
Thanks for the help!
David _________________ "The only people who inherit anything by right of birth are congenital idiots" -- Asimov |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Wed Jan 21, 2004 4:07 pm Post subject: |
|
|
David,
I am suggesting that it is four 6-bit bytes:
Device, Function, Device complement, function complement.
The notation was created by John Fine and it means:
{38K,562, MSB} IR carrier frequency=38KHz, Time base(TB)=562 uSec, bits are MSB first
<1,-1|3,-1> Zero|One definition in units of TB
(8,-4, Lead in in units of TB
D:6,F:6,~D:6,~F:6, Order of data bits
-33)+ final lead out or gap in units of TB and the + means the entire expression between parenthesis repeats as long as the button is held.
Also the numerals in the word document will be OBC's but since KM Master doesn't understand this protocol you need to multiply OBC's by four since UEIC remotes always assume the bottom bits are on the left. _________________ -Jon |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Wed Jan 21, 2004 4:14 pm Post subject: |
|
|
jon_armstrong wrote: |
I am suggesting that it is four 6-bit bytes:
|
Why?
The pdf documents a 12 bit msb "data" field, and documents the meaning of almost every possible value of data from 00 hex through 94 hex (and none outside that range).
If you look ant the meanings of data values 3F hex and 40 hex, it becomes very hard to sustain the theory that there is any interesting boundary between the low six bits and the bits above those.
Do you see something I don't or vice versa? |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Wed Jan 21, 2004 4:20 pm Post subject: |
|
|
Oops. I didn't actually try the above link before since I had already downloaded the PDF file. But that link doesn't go to that PDF file. It goes to a .doc file whose list of commands ends at 3E hex. So that is what Jon saw that I didn't. |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Wed Jan 21, 2004 5:20 pm Post subject: |
|
|
OK, I just found the pdf http://www.sunfire.com/support.htm and John is correct since the commands go at least to decimal 148 so it is indeed:
{38K,562, MSB}<1,-1|3,-1>(16,-8,D:4,F:8,~D:4,~F:8,-33)+
And David, this simplifies the OBC entry. You no longer should multiply by four.
BTW, John, IRTools doesn't seem to decode this protocol even with DecodeIR.dll v 2.11 _________________ -Jon
Last edited by jon_armstrong on Sun Jan 25, 2004 2:36 pm; edited 1 time in total |
|
Back to top |
|
|
Guinness
Joined: 21 Jan 2004 Posts: 5 Location: Arlington, VA |
Posted: Sat Jan 24, 2004 4:24 pm Post subject: |
|
|
I haven't had any luck so far with building this protocol. I am confused about how to represent the ~D:4,~F:8 portion. I have tried to use the XOR and XOR-Comp for check bytes, but this function isn't documented very well and my boolean logic is rusty... I don't see how XOR would invert a signal, and I just don't even know what "XOR-Comp" means (exclusive NOR?). Am I totally on the wrong track here? I'll paste my protocol failure here for you to laugh at: <grin>
Upgrade protocol 0 = 01 23 (S3C8)
3D 92 48 8B 12 DF 09 08 08 03 48 01 04 01 18 01
04 24 36 11 94 08 B6 8D 01 46
End
Thanks again,
David _________________ "The only people who inherit anything by right of birth are congenital idiots" -- Asimov |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Sat Jan 24, 2004 6:11 pm Post subject: |
|
|
It's in "Signal Structure" pull down box for "dev-cmd-!dev-!cmd".
You were on the right track, but If you have a structure like dev-cmd-cmd! you do use the XOR-Comp feature and pick only one previous byte and it XOR's with FF. _________________ -Jon |
|
Back to top |
|
|
Guinness
Joined: 21 Jan 2004 Posts: 5 Location: Arlington, VA |
Posted: Sun Jan 25, 2004 12:46 pm Post subject: |
|
|
I've had that signal structure selected from the start, so I guess that's not the problem. I have no bit doubling, no repeat value, no check byte, lead-in on first frame only, lead-out style 0 "off as total", no alt lead-out, and no toggle bit. I have switched all of these settings with no success... is there anything I can show you that might give you a clue as to what my problem is? Here is the code from a learned signal (VOL-) on my RCU810:
+8972 -4484 +584 -554 +584 -554 +584 -554 +584 -554 +584 -554 +584 -554 +584 -554 +584 -554 +1704 -548 +1704 -548 +584 -554 +1704 -548 +1704 -548 +1704 -548 +1704 -548 +1704 -548 +1704 -548 +1704 -548 +1704 -548 +1704 -548 +584 -554 +584 -554 +1704 -548 +584 -18082
It looks just like the hex code from the Sunfire Pronto document, but maybe it has a clue somewhere... _________________ "The only people who inherit anything by right of birth are congenital idiots" -- Asimov |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Sun Jan 25, 2004 2:45 pm Post subject: |
|
|
I just posted a file in the JP1 Yahoo group files|devices|TV|Sunfire.zip that has both the device and protocol upgrades. I did see one mistake that I made in the definition:
{38K,562, MSB}<1,-1|3,-1>(16,-8,D:4,F:8,~D:4,~F:8,-33)+
I originally had the lead in as (8,-4, ... ) and I corrected that. You would use the same lead-in for every frame.
At any rate, I tested OBC 13 and it decodes correctly.
+8950 -4546 +550 -572 +550 -572 +550 -572 +550 -572 +550 -572 +550 -572 +550 -572 +550 -572 +1680 -566 +1680 -566 +550 -572 +1680 -566 +1680 -566 +1680 -566 +1680 -566 +1680 -566 +1680 -566 +1680 -566 +1680 -566 +1680 -566 +550 -572 +550 -572 +1680 -566 +550 -19134
You can load my protocol file text image (Sunfire-PB.txt) into PB with the load command and compare mine to yours and more importantly test the device upgrade and see if it works. I didn't assign many buttons in the buttons tab since you can chose those and put the commands where you want them. The protocol has already been entered in the KM Master device upgrade so the PB text file is just FYI. _________________ -Jon |
|
Back to top |
|
|
Guinness
Joined: 21 Jan 2004 Posts: 5 Location: Arlington, VA |
Posted: Sun Jan 25, 2004 5:02 pm Post subject: |
|
|
I misunderstood the device and command bytes sections. I also had the lead-in style wrong. Your protocol and upgrade work perfectly. I assigned most of the buttons, and now I'm playing around with macros and such. Thanks so much for your help!
One note, though: Sunfire is Bob Carver's new company, and they don't make TVs. This protocol is for their latest pre-amps and receivers.
David _________________ "The only people who inherit anything by right of birth are congenital idiots" -- Asimov |
|
Back to top |
|
|
jon_armstrong Expert
Joined: 03 Aug 2003 Posts: 1238 Location: R.I.P. 3/25/2005 |
Posted: Sun Jan 25, 2004 5:20 pm Post subject: |
|
|
David,
I moved the file over to the Audio section and changed the names. I don't know where I got TV??
Glad it worked for you. _________________ -Jon |
|
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
|