Amino set-top box Aminet110

[AndrewZ]

What do the 4 color buttons do for this device? Are they teletext buttons? Do they ever serve any other purpose?

Sure! They are acting like 'soft keys' and have dynamic assignments. For example Red is not active all the time, but if it is active it works as 'Lock the channel'. Blue is used a 'Channel Guide', and so on.
Those keys are available at the bottom of TV screen while you're in menu or 'normal' TV mode for a few soconds after the channel change. You may see the colour of the key and it's description, like in teletext.

I've tested unused OBC's - it seems that they are really unused.

Thanks a lot!

[The Robman]

Do they change purpose? like would red ever be anything except "lock the channel" and would blue ever be anything except "Guide"? If these buttons all have just one non-teletext purpose, I'd like to list what they do in the upgrade file as it help us decide what buttons to assign them to on remotes that don't have coloured buttons. For example, based on your info, I would probably assign Blue to the Guide button.

[AndrewZ]

normally the meaning of those buttons is controlled by provider and configured through the software ("middleware") which interacts with the STB embedded software

this is what I have

while watching TV channel:
red - lock
blue - channel guide

while in the channel list, pointing to the channel you're subscribed to:
red - lock
yellow - about
blue - guide

while in the channel list, pointing to the channel you're not subscribed to:
red - lock
green - subscribe
yellow - about

[v.korotkov]

Is it possible to make a lirc config file for AmiNET110 using all you've discovered here?

Thanks in advance!

[orinoco]

Please help with the lirc file, thanks in advance!

[The Robman]

To understand the checksum, first download the spreadsheet. Column K is the captured checksum and columns M thru P are the calculated checksum. It's entirely possible that I have come up with formula for the checksum that is more complicated than it needs to be, so if you spot an easier way to do it that would be great, but it does appear to work.

When I refer to bits by number in this description, I am using the same numbering that I have to use in Excel, so I'm numbering them 1 thru 8 counting from the left (rather than the traditional 0 thru 7 counting from the right).

I have defined a named item called "big3" which is defined as OBC bits 4, 7 and 8 multiplied together, so if all three of those bits are set (to 1) the big3 item is also set.

The formula for the first checksum bit is:
=MOD(MID($E2,5,1)+(big3*MID($I2,6,1))+MID($I2,5,1)+(MOD(MID($I2,6,1)+big3,2)*$F2),2)

That means...
1) take dev-5 (ie, the 5th bit of the 5-bit device code)
2) if big3 is set, take OBC-6 (ie, the 6th bit of the OBC)
3) take OBC-5
4) if either big3 or OBC-6 are set (but not both), take the toggle bit

and XOR them all together.

The next checksum formula is:
=MOD($F2+MID($I2,6,1)+big3,2)

Which means...
1) take the toggle bit
2) take OBC-6
3) take the big3

and XOR them all together.

The next checksum formula is:
=MOD(MID($I2,7,1)+(MID($I2,8,1)*MID($I2,4,1)),2)

Which means...
1) take OBC-8
2) take OBC-4
3) multiply them together (so both need to be 1 for the result to be 1)
4) take OBC-7

and XOR OBC-7 with the result from step 3.

The next checksum formula is:
=MOD(MID($I2,8,1)+MID($I2,4,1),2)

Which means...
1) take OBC-8
2) take OBC-4

and XOR them all together.

Like I said earlier, I would not be surprised if there's a simpler formula for this checksum, especially the first bit, but this is what I put in the spreadsheet.

[mathdon]

I have taken the IRP for this one as

AminoN {55.5k,270,msb}<-1,1|1,-1>(7,-6,3,D:5,P:1,X:2,S:8,F:8,~Y:4,C:4,^77m)+

where P is 1 for the first frame and 0 for all repeats
and N can be 0 to 15 but is omitted if it is 0.

C is a checksum that is compared with a 4-bit value S given by

S:1:0 = F:1:0 ^ F:1:4
S:1:1 = F:1:1 ^ (F:1:0 & F:1:4)
S:1:2 = P:1 ^ F:1:2 ^ Z
S:1:3 = D:1:0 ^ (Z & F:1:2) ^ F:1:3 ^ ((Z ^ F:1:2) & P:1)

where Z = F:1:0 & F:1:1 & F:1:4.

N is the XOR of C and S, which is 0 and therefore omitted from the protocol name if the checksum matches this formula (due to Rob). Rob, your post gave an equivalent of S:1:1 = F:1:1 ^ F:1:4, but it changed half way down your spreadsheet and the one I've given is your second one, that works for all the signals.

The values of X and Y are given in the Misc field. In the .ir files we have, X=1, Y=0 throughout. I've complemented Y for no other reason than it is nicer to report this "standard" value as 0 rather than 15.

I hope this is a proper use of IRP. F:1:4, for example, here means one bit of F starting at bit 4 (with the conventional labelling of bits, bit 0 being the least significant), ^ is Exclusive OR and & is logical AND.

The DecodeIR output is

Code: Select all

LEARNED SIGNALS:
LEARNED CODE DATA
# 	Btn	Key	   P'col   Dev Sub OBC  Hex  EFC   Misc
1 	TV 	1     	Amino	1	0	2 	02	034	X=1 Y=0	
2 	TV 	2     	Amino	1	0	3 	03	026	X=1 Y=0	
3 	TV 	3     	Amino	1	0	4 	04	242	X=1 Y=0	
4 	TV 	4     	Amino	1	0	5 	05	234	X=1 Y=0	
5 	TV 	5     	Amino	1	0	6 	06	002	X=1 Y=0	
6 	TV 	6     	Amino	1	0	7 	07	250	X=1 Y=0	
7 	TV 	7     	Amino	1	0	8 	08	082	X=1 Y=0	
8 	TV 	8     	Amino	1	0	9 	09	074	X=1 Y=0	
9 	TV 	9     	Amino	1	0	10	0A	098	X=1 Y=0	
10	TV 	0     	Amino	1	0	12	0C	050	X=1 Y=0	
11	TV 	Up    	Amino	1	0	21	15	106	X=1 Y=0	
12	TV 	Down  	Amino	1	0	25	19	202	X=1 Y=0	
13	TV 	Left  	Amino	1	0	22	16	130	X=1 Y=0	
14	TV 	Right 	Amino	1	0	24	18	210	X=1 Y=0	
15	TV 	Select	Amino	1	0	23	17	122	X=1 Y=0	
1 	TV 	Ch+   	Amino	1	0	17	11	138	X=1 Y=0	
2 	TV 	Ch-   	Amino	1	0	20	14	114	X=1 Y=0	
3 	TV 	Last  	Amino	1	0	11	0B	090	X=1 Y=0	
4 	TV 	+100  	Amino	1	0	13	0D	042	X=1 Y=0	
5 	TV 	Power 	Amino	1	0	1 	01	010	X=1 Y=0	
6 	TV 	Menu  	Amino	1	0	18	12	162	X=1 Y=0	
7 	TV 	Red   	Amino	1	0	26	1A	226	X=1 Y=0	
8 	TV 	Green 	Amino	1	0	27	1B	218	X=1 Y=0	
9 	TV 	Yellow	Amino	1	0	28	1C	178	X=1 Y=0	
10	TV 	Blue  	Amino	1	0	29	1D	170	X=1 Y=0

Is this OK?
________________
Graham

[The Robman]

Rob, your post gave an equivalent of S:1:1 = F:1:1 ^ F:1:4, but it changed half way down your spreadsheet and the one I've given is your second one, that works for all the signals.

You're right, I hadn't noticed that, so thanks. I've edited my post to reflect this.

I've looked over your IRP code (where I assume ^ means XOR and & means "multiply") and it all looks good. However, I'm not an IRP expert, so maybe John needs to comment also, as he is *the* IRP expert!

One note though, if it were up to me, I wouldn't start using P or "position" for bits that we've always referred to as "toggle" bits. I understand why you're doing it, because you want to use the term "toggle" just for protocols like RC5 where the starting value changes each time, but we also use the term for protocols like this where the starting value is constant and it changes value just for the repeats. (I agree with your use of the term "position" for IODATA though, where it's a 2-bit code with 3 possible values).

[mathdon]

OK, Rob, I'll go back to using T. I thought that was used exclusively for protocols where the value remains fixed throughout the repeats of each keypress, but toggled between keypresses.

Yes, ^ means XOR and & means AND, as for single bit values, AND and multiply are the same thing.

I hope John will comment on the IRP. I've also posted a potential IRP for Telefonica which I would like reviewed before I attempt to add that one into DecodeIR.
____________
Graham

[The Robman]

I don't think we have a fixed meaning for the term "toggle", though John might have some different views on this.

Here's a challenge for you, do you think you would be able to write a new program to replace DecodeIR that uses an IR file as input? So, when we document a new protocol all we need to do is add an entry to the IRP file and DecodeIR will magically start recognize it.

[mathdon]

Here's a challenge for you, do you think you would be able to write a new program to replace DecodeIR that uses an IR file as input? So, when we document a new protocol all we need to do is add an entry to the IRP file and DecodeIR will magically start recognize it.

I've thought about that, Rob, but I don't think it is possible. Distinguishing one protocol from another is a fine art. Make the restrictions too strict and you won't recognise badly learned signals or ones learned from remotes that are not quite true, eg learns of learns. Make them too loose and you get too many spurious decodes. There are already a number of cases - and I've already had to add one more - where John has had to make one protocol pre-empt another, to prevent a spurious decode occurring in addition to the correct one. This is why John needs to test my additions against his database, to see if my restrictions are perhaps too strict or too loose.
_____________
Graham

[The Robman]

Maybe you could add a % in the entry to tell the program how strict to be with a particular protocol, and you could also add a priority code that could be used as a tie-breaker between similar protocols.

[mathdon]

I have been looking further into this protocol in my efforts to create protocols.ini entries for the protocols I have added to DecodeIR. The executor needs to calculate the rather curious checksum, since it has to deal with whatever values for Device, Function etc are provided by the user, so I have tried to see if there is something more systematic in the checksum than appears at first sight. I think there is, though it is not as systematic as I would like. Here is what I have come up with.

The protocol has Device (D), Subdevice (S) and Function (F) codes that are each 8-bit, and in addition an 8-bit checksum (C). There is also an 8-bit toggle mask M with M=4 for the example we have been given, though I see no reason why M cannot vary, providing different versions of the protocol. There is an 8-bit toggle parameter T with T=0 for the first frame and T=M for all repeat frames. The IRP is

Amino {55.5k,270,msb}<-1,1|1,-1>(7,-6,3,(D^T):8,S:8,F:8,C:8,-77m)+

where C = (D^T^S^F^FF^(((F^FF)&(T^M))<<1))|$F0 with FF = F:1:4*((F<<1)&(F<<2)&(F<<3)) .

The notation X<<n, created by me for this protocol, means X shifted left n places, with 1's filling the empty places to the right. (Note that this differs from the same notation in C++, where the empty places would be filled with 0's).

These are the things I find unsatisfactory. The top four bits of C are forced to 1 by the "or $F0" at the end of its definition. I suspect that if we had examples with greater variation in the top four bits of the data fields then it would be possible to create a checksum that genuinely used all 8 bits. The F<<n terms ANDed together in FF could be extended to all n from 1 to 7 as nothing would change for the data in our sample, but it could not include F<<0. Finally, the singling out of bit F:1:4 is odd, to say the least. There is in fact no need to include S in the construction of C, as S=0 in our sample, but I've done so as it seems to fit naturally.

If nothing else, this provides a relatively easy way to calculate the checksum in an executor, and to check it in DecodeIR. Note that in decoding, the first frame alone is enough to identify D, S and F but not to check the checksum since M is unknown. If there is at least a second frame, my code in DecodeIR compares the two, determines M and validates the checksum. Since the checksum probably does not hold true for general D, S and F, DecodeIR "XORs" the calculated and actual checksums and, if nonzero, it returns the result as a parameter N. If it has only one frame to work with, it reports M and N as undetermined. The sample we have has D=13, S=0, T=4.

Here is a protocols.ini entry with HCS08 and S3C8+ code that generates this protocol for arbitrary toggle mask M and checksum seed N:

Code: Select all

[Amino]
PID=01 FC
DevParms=Device:8=13,Sub Device:8=0,M:8=4,N:8=0
DeviceTranslator=Translator(2,8) Translator(3,8,8) Translator(0,8,16) Translator(1,8,24) 
CmdParms=OBC:8=0
CmdTranslator=Translator(0,8)
FixedData=04 00 0D 00
Code.HCS08=20 1A 18 30 41 8F 84 10 08 08 00 87 00 87 00 87 00 87 96 64 01 95 00 00 03 B1 03 2A 3C AA 4E AA AC A6 FF AE 03 B4 64 99 49 5B FA 08 64 01 4F B7 65 B8 64 B4 60 99 49 45 00 05 E8 60 5B FC AA F0 B7 65 AE 7A CD FF 65 CD FF 5F B6 62 B8 60 B7 62 3F 60 CD FF 92 25 CA 81
Code.S3C80=2E 5E 41 8B 17 8F 84 10 08 08 00 87 00 73 00 87 00 73 96 64 01 95 00 00 03 B1 03 16 20 11 E4 11 01 1C FF 2C 03 54 07 C1 DF 10 C1 2A F8 28 07 37 29 02 B0 C1 19 08 B4 07 C1 54 03 C1 DF 10 C1 2C 08 4C 05 B3 12 00 C2 4A FA 46 C1 F0 19 08 1C 22 F6 01 4C F6 01 46 B4 03 05 B0 03 F6 01 0A 7B C1 AF

I've arbitrarily used a PID of 01FC. It would be nice to have some policy on PIDs created by this forum, though I see no way of avoiding possible clashes with ones issued by UEI in the future. I believe RM has a facility for using an Alternate PID if the main PID is built in to the remote, so perhaps we could create two for each protocol to minimise the risk?
________________
Graham

[Capn Trips]

PLEASE do not use 01FC. That is the DSM Protocol in every extender that I have ever seen.

[vickyg2003]

Typically we assign 01FF to any custom protocol, and then it can be adjusted if the user has to use more than one custom protocol.