|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Wed Jul 29, 2009 11:37 am Post subject: |
|
|
It looks good, though you're missing the leadout time (which should be about -77810 uS). It took me a moment to figure out what the "7:3,0:3,1:1" part was all about, I think I'd prefer to see the "+930 -930" leadin represented differently.
I'm not confident that I know how to write IRP, but I think it should look something like this:
Telefonica {56.3k,310,msb}<1,-3|-1,1,-2|-2,1,-1|-3,1>(3,-3,1,D:8,S:8,F:8,C:8,-251)+ _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Thu Jul 30, 2009 3:21 am Post subject: |
|
|
You're absolutely right, of course, Rob. I was trying to unscramble this protocol in my mind, but the protocol won. Scrambled brains!
What I was trying to do was indicate that the pulse trains for the bit pairs were not as unsystematic as they first seem, but I encoded the wrong pulse times. It was intended to come out as
Telefonica {56.3k,310,msb}<-1|1>(3,-3,1,<8:4|4:4|2:4|1:4>(D:8,S:8,F:8,C:8,^77m))+
It would seem even more systematic if one could write
Telefonica {56.3k,310}<-1|1>(3,-3,1,<1:4|2:4|4:4|8:4>{msb}(D:8,S:8,F:8,C:8,^77m))+
as the encoding of the bit pairs makes more sense in lsb form while the encoding of the data in those bit pairs is in msb form. But I've never seen anything John has written looking quite like either of these, so I await his judgement.
While I'm seeking John's view, could I also ask about the notation IRP uses for lead-outs. I've written ^77m there, which I think means "upwards of 77 milliseconds" but I'm not really sure of the meaning of the ^. There are also lead-outs given as "???". Does that mean "unknown" or does it have some quantitative meaning?
______________
Graham |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Thu Jul 30, 2009 7:04 am Post subject: |
|
|
Changing the bit definitions mid stream, even using the outer to define the inner, is fine.
I don't like adding {msb} mid stream. There is a format for reversing an individual field (but I forget what it is). In your case, if the important data is msb why do you need to start with lsb?
In irp notation, the ^ for lead out time means the lead out makes up the difference such that the total back to the last open paren adds up to that time. If you want a simple, fixed duration lead out, that is just - instead of ^.
There is no ??? in irp notation. There is just a person who got lazy when writing many of the irp strings and didn't bother to compute some values and wrote ??? instead. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Thu Jul 30, 2009 7:31 am Post subject: |
|
|
Also, I believe, that if you don't specify a unit for the leadout time, it's treated as multiples of the time base, so in my example as I was aiming for 77810 uS I entered -251 (ie, 251 * 310 = 77810). _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Thu Jul 30, 2009 11:06 am Post subject: |
|
|
johnsfine wrote: | Changing the bit definitions mid stream, even using the outer to define the inner, is fine. | That's good, thanks.
johnsfine wrote: | I don't like adding {msb} mid stream. There is a format for reversing an individual field (but I forget what it is). In your case, if the important data is msb why do you need to start with lsb? |
I didn't think you would like it. Why did I want to do it? Only for the very mild reason that I thought having the two-bit values for 0,1,2,3 encoded by the 4-bit values for 1,2,4,8 was more elegant than this being by 8,4,2,1. But I'm not the slightest bit fussed about not being able to do it.
The "I forget what it is" puzzles me - I thought you invented IRP and that the only full spec of it was in your head.
johnsfine wrote: | In irp notation, the ^ for lead out time means the lead out makes up the difference such that the total back to the last open paren adds up to that time. If you want a simple, fixed duration lead out, that is just - instead of ^.
There is no ??? in irp notation. There is just a person who got lazy when writing many of the irp strings and didn't bother to compute some values and wrote ??? instead. |
That's an excellent clarification. Many thanks.
The Robman wrote: | Also, I believe, that if you don't specify a unit for the leadout time, it's treated as multiples of the time base, so in my example as I was aiming for 77810 uS I entered -251 (ie, 251 * 310 = 77810). |
Yes, I had got that bit. I have put it as ^77m (though I think I have to up that a bit now I have John's explanation) as I don't feel lead-out times are as accurate as -251 suggests.
_______________
Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Thu Jul 30, 2009 11:13 am Post subject: |
|
|
I believe this protocol uses a fixed leadout time, rather than an "off as total" leadout time, so you don't want to use the "^" prefix on the leadout time.
Also, leadout times don't need to be that accurate, and you can certainly be off by more than 310 uS and still be correct, so using a multiple of 310 is fine. Having said that, I personally prefer to see the leadout time specified as a time rather than a multiple because it saves the user the extra step of needing to convert it. _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Fri Jul 31, 2009 6:07 am Post subject: |
|
|
I have finished up putting the IRP for Telefonica (and Sejin) in the forms
Telefonica {56.3k,310,msb}<-1|1>(3,<8:4|4:4|2:4|1:4>(3:2,D:8,S:8,F:8,C:8,-77m))+
Sejin {38.8k,310,msb}<-1|1>(3,<8:4|4:4|2:4|1:4>(3:2,D:8,S:8,F:8,C:8,-77m))+
where C = D:4:0 + D:4:4 + S:4:0 + S:4:4 + F:4:0 + F:4:4.
Rob, you may think it a step backwards to put the 3:2 at the start of the data, instead of -3,1 before the data, but this is best for decoding. If you treat -3,1 as part of the leadin then the data may start in the middle of an ON pulse, which is difficult to handle. Having 3:2 in the data both gives data that starts at an ON/OFF boundary and gives an easy check on that OFF/ON pair. Also, it isn't very obvious that -3,1 does correspond to a bit pair and this makes it clearer to any future coders of protocol executors or decoders.
I'm only giving the output from one of the files, but the others do decode properly too. Telefonica and Sejin are distinguished by frequency. The first Telefonica file decodes as
Code: | LEARNED SIGNALS:
LEARNED CODE DATA
# Btn Key Protocol Dev Sub OBC Hex EFC Misc Note
1 TV 1 Telefonica 16 0 89 59 200 Numeric 1
2 TV 2 Telefonica 16 0 105 69 073 Numeric 2
3 TV 3 Telefonica 16 0 121 79 201 Numeric 3
4 TV 4 Telefonica 16 0 28 1C 178 Numeric 4
5 TV 5 Telefonica 16 0 44 2C 051 Numeric 5
6 TV 6 Telefonica 16 0 60 3C 179 Numeric 6
7 TV 7 Telefonica 16 0 76 4C 048 Numeric 7
8 TV 8 Telefonica 16 0 92 5C 176 Numeric 8
9 TV 9 Telefonica 16 0 108 6C 049 Numeric 9
10 TV 0 Telefonica 16 0 29 1D 170 Numeric 0
11 TV Guide Telefonica 16 0 106 6A 097 GUIA TV
12 TV Mute Telefonica 16 0 107 6B 089 MUTE
|
_______________
Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Fri Jul 31, 2009 2:02 pm Post subject: |
|
|
mathdon wrote: | Rob, you may think it a step backwards to put the 3:2 at the start of the data |
I'm OK with that actually, it's the nesting I'm not so keen on. How about this instead...
Sejin {38.8k,310,msb}<-1|1><8:4|4:4|2:4|1:4>(3,3:2,D:8,S:8,F:8,C:8,-77m)+
The $0161 executor seems to allow for signals both having a "break" string and not. It also allows for both the 38kHz and 56kHz carrier frequencies. There's some other stuff in there too but I haven't documented it all yet.
With regards to naming this protocol, I don't like the idea of using completely different names for each implementation of it (ie, Telefonica vs. Sejin vs. ADB, etc). It appears that the protocol really belongs to Sejin, as they're the folks who actually make the STBs and their name appears in the Telefonica doc, so I would like to name the protocol "Sejin". As you need a way of differentiating between the 38k version and the 56k, you could use the names Sejin-38 and Sejin-56. When you detect a "break" string, you could perhaps relay that info via Misc, as that will probably be a user selection in RM.
Sejin-38 {38.8k,310,msb}<-1|1><8:4|4:4|2:4|1:4>(3,3:2,D:8,S:8,F:8,C:8,-77m)+
Sejin-56 {56.3k,310,msb}<-1|1><8:4|4:4|2:4|1:4>(3,3:2,D:8,S:8,F:8,C:8,-77m)+ _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Fri Jul 31, 2009 5:03 pm Post subject: |
|
|
Rob, I'm completely happy with everything you suggest. I know absolutely nothing about the origin of these protocols, manufacturers etc. My names are virtually random and I've been waiting for someone to tell me better ones. My only questions are:
Is John happy with <-1|1><8:4|4:4|2:4|1:4> without any intervening brackets, and
What is a "break string"? Is that the "Extra" frame? As I've said elsewhere, due to DecodeIR not getting the Extra frame I've no way of distinguishing its presence or absence.
Please remember that, so far, I know nothing about PB or what's in the executors. I've just been working from the .ir files people have posted. So if you, or John, or anyone, can tell me the full flexibility of the $0161 executor in terms I currently understand, such as in IRP notation, I will be happy to extend/modify the decode to meet it.
_______________
Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Fri Jul 31, 2009 5:48 pm Post subject: |
|
|
The term "break" comes from infrared keyboards where the protocols tend to have a "make" (ie, sent once when the button is pressed) and a "break" (ie, sent when the button is released) portion.
I'm using the term to refer to the portion of the signal that gets sent when the button is released. This portion would normally show up as an "extra" in learned signals, but that doesn't mean that everything that turns up in "extra" is a "break" signal.
Actually, I think you do need a set of brackets in this IRP, so my suggestion would be:
Sejin-38 {38.8k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,D:8,S:8,F:8,C:8,-77m))+
Sejin-56 {56.3k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,D:8,S:8,F:8,C:8,-77m))+
So all I'm really doing is moving the '3' to the main section rather than have it all alone up front.
Also, protocols and executors don't have to have a 1-to-1 relationship. We can decide that an executor is capable of generating more than one protocol, if we wish, and we have certainly seen protocols generated by more than one executor.
I'm assuming that you can read assembler, so at some point, you should take a look at an executor to see how it works, if for no other reason than curiosity. Plus, for simple protocols you don't even need assembler as PB does it all for you. _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Aug 01, 2009 3:37 am Post subject: |
|
|
The Robman wrote: | I'm assuming that you can read assembler, so at some point, you should take a look at an executor to see how it works, if for no other reason than curiosity. Plus, for simple protocols you don't even need assembler as PB does it all for you. |
Oh yes, since I've written an extender I think I can read assembler! But I'm only familiar with HCS08 assembler. I think I should also learn to read S3C8 assembler. Can you point me to an S3C8 datasheet?
As for looking at protocol executors, it won't just be for curiosity. But I've been rather busy lately, as you might have noticed!
_____________
Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Sat Aug 01, 2009 11:23 am Post subject: |
|
|
You've certainly been keeping yourself busy in the JP1 world! As if taking on IR.exe wasn't enough (and I know it turned out to be more than you expected) now you're taking on DecodeIR. Amazing.
You can get a copy of the S3C8 instruction sheet here:
http://www.hifi-remote.com/files/ _________________ 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sat Aug 01, 2009 2:56 pm Post subject: |
|
|
I got hooked! I did only start on IR.exe as it didn't cope very well with my remote, a URC-7781, but since I got to understand the program I thought I would do a bit more, to help others. And I sort of stayed! But IR.exe uses DecodeIR, and that was getting out of date since John couldn't spare the time, so one thing led to another! I just love the challenge of programming!
_____________
Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Sat Aug 01, 2009 3:46 pm Post subject: |
|
|
We have plenty here to keep you busy, so tell your friends and family that you may be away for a while! _________________ 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 |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
|
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
|