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

PID $016C: XMP Protocol
Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
johnsfine
Site Admin


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

                    
PostPosted: Fri Mar 13, 2009 3:12 pm    Post subject: PID $016C: XMP Protocol Reply with quote

Any chance Rob or Greg might add an XMP entry to protocols.ini so these upgrades that have been mentioned in a few threads recently could come up in RM as "XMP" with numbering consistent with the decodes, rather than "Dreambox" with different numbers?

I've forgotten how (I remember enough about protocols.ini, but not enough about Pid016C). I did that for XMP once, but I seem to have overwritten that copy, apparently after messing up my attempt to check it into SourceSafe CVS.
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: 21211
Location: Chicago, IL

                    
PostPosted: Fri Mar 13, 2009 4:25 pm    Post subject: Reply with quote

I've been meaning to write something up for the XMP protocol to get decodeIR and RM in sync. I've just gotta say that I really hate this protocol, it's one of the most time consuming protocols to try and decode by hand. Plus, UEI learning remotes have a problem getting the learns just right and sometimes the burst pair that is saved is exactly half way between two valid pairs, so you don't know which to chose. They also manage to completely drop some of the pairs.

Furthermore, the Slingbox chips have a problem with it too. If it's not already in the Slingbox, it's too big to load as an upgrade. If it is in the Slingbox, the timings don't work properly, so I always have to create special protocols that adjust the timings. I think the Slingbox processor is faster than those in remote controls, therefore the timings need to be reduced, but this is just a guess.

This executor uses two variable bytes, but none of the devices that use it really need two variable bytes. They all either use var-byte1 or var-byte2 as the OBC byte, and the other byte is always zeroes. So, I think we should refer to this executor as XMP-1 and XMP-2, where XMP-1 uses the first variable byte and XMP-2 uses the second. (Of course, DecodeIR won't know which to pick when OBC zero is used).

There's a toggle in the signal and a couple of checksums.

Let's take a sample of the signal:

**part1* - **part2* - description
170F443E - 1A003200 - sent once
170F443E - 12803200 - repeating signal

The first 4 bytes are the fixed data that is fed into the executor. The 2nd nibble of each 4-byte set is a SUM of all the other seven nibbles in the set.

The toggle is the rightmost bit of the 3rd nibble of the 2nd part of the signal (ie, 0 changes to 8 in this example, which in turn causes the checksum to change from A to 2).

Nibbles 4-6 of part1 are always "F44", at least in every example that I've seen, so the only fixed data that varies is the 1st nibble, 3rd nibble and the 4th byte.

Part1:
The 1st nibble is variable (but it's usually 1).
The 2nd nibble is the checksum.
The 3rd nibble is variable (but it's usually 0).
The 4th nibble is always "F"
The 3rd byte is always "44"
The 4th byte is the main device code.

Part2:
The 1st nibble is a repeat of the 1st nibble from part1.
The 2nd nibble is the checksum.
The 3rd nibble is the toggle.
The 4th nibble is a repeat of the 3rd nibble from part1.

XMP-1
The 3rd byte is the OBC.
The 4th byte is zeroes.

XMP-2
The 3rd byte is zeroes.
The 4th byte is the OBC.

We could assign "device code 1" to the 4th fixed byte. We could combine the 1st and 3rd nibbles as "device code 2". The 4th nibble and 3rd byte could be OEM codes, that way we can change them if needed.

As very few remotes have the $016C executor built in, I would recommend that we provide a reduced version that uses 1 variable byte if it's requested for a remote that doesn't have it.

For remotes that do have it (like the 15-135), if the user selects XMP-1, the OBC data should get dropped into the 1st variable byte, and if the user selects XMP-2, it should get dropped into the 2nd variable byte.

For DecodeIR, as long as the middle portion of the fixed data is "F44", it could provide the data as described above. If the data is different, it could append the new data to the protocol name. For example, if the fixed data was "170D433E", it could display the protocol as XMP-170D433E-1 or XMP-170D433E-2 (depending on whether the 1st or 2nd OBC byte was used).

Given how hard it can be to differentiate between some pairs, expecially the $E and $F pairs, I think it would be a good idea for DecodeIR to use the checksum nibble as a way of validating the data. If the OBC byte is half way between 0E and 0F, for example, check which value would generate the value found in the checksum nibble and go with that one. Be aware, of course, that the checksum pair could also be between two values, so you would need to decide which pair you have the greater confidence in.

Here's how you can calculate the checksum:

1) convert each nibble (except for the checksum nibble) to decimal
2) ADD all the decimal values
3) subtract the result from 256
4) MOD it with 16 (ie, divide by 16 and keep the remainder)
5) convert the result back to 1 nibble of hex.

For anyone else who's interested, here are the 16 pairs used by this protocol:

0 = +210 -750
1 = +210 -890
2 = +210 -1030
3 = +210 -1170
4 = +210 -1310
5 = +210 -1450
6 = +210 -1590
7 = +210 -1730
8 = +210 -1870
9 = +210 -2010
A = +210 -2150
B = +210 -2290
C = +210 -2430
D = +210 -2570
E = +210 -2710
F = +210 -2850
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Tue Dec 01, 2009 6:09 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


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

                    
PostPosted: Tue Dec 01, 2009 5:33 pm    Post subject: Reply with quote

I've figured out one of the main reasons why this protocol is so hard to learn using a JP1 remote. As described above, the protocol uses up to 16 different burst pairs for the data, plus another 2 for the leadout pairs, making a potential total of 18 pairs.

UEI learning remotes have a limit of 10 pairs that they can capture, so once the remote has captured 10 unique pairs, any further pairs are just dropped, which explains why some digits are missing when you decode the signals.

I recently decoded the learns for a Pace box that uses the XMP protocol where there were lots of digits missing from the decodes. In most cases, the missing digits are from the repeating portion of the signal, so you can still get the OBC from the main part, but there were about half a dozen buttons where the 10 pair limit was reached before the OBC portion of the signal, which made them impossible to decode.

The following zip file contains the learns that I was given for this Pace box, along with a spreadsheet which shows the decoded data next to what the data should have looked like. I derived the correct OBCs from an upgrade that I was given by UEI.

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7584

In addition to missing digits, you'll notice that some of the higher pairs (eg, pairs A thru F) are more likely to decode incorrectly, where they are off by 1.

I'm presenting this information in case John or Graham have any ideas about how DecodeIR can do a better job of decoding the signals even with certain pairs missing. For example, maybe it could keep track of how many pairs have been encountered so far, so once the 10 limit has been reached it could be on the lookout for missing pairs. As the missing pairs are more often from the repeating portion of the signal, and it's often the toggle bit that's dropped, maybe DecodeIR could not report the repeating portion as a GAP protocol.

For signals where the 10 limit is reached before the OBC portion of the signal is encountered, maybe DecodeIR could still report the signal as XMP and instead of listing an OBC, report an error of some sort.
_________________
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
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Jan 02, 2010 12:45 pm    Post subject: Dreambox/XMP protocol Reply with quote

In another thread mathdon wrote:
Quote:
I have discovered that WinZip is capable of adding new Java class files into a .jar file, so given the Grundig16 entry for the text file protocols.ini and the compiled GrundigXlator.class file, users of RemoteMaster can then add this protocol themselves if they wish.

Do I understand this correctly? Is this applicable to the Dreambox/XMP situation, where RM usage of device numbers differs from DecodeIR.dll?

Currently, RM handles the Dreambox/XMP protocol by requiring the entry of 4 device numbers, which are simply the decimal equivalents of the 4 bytes of fixed data. The values of these 4 device numbers are different than the 2 device numbers that DecodeIR.dll reports. The second nibble of the fixed data is the arithmetic sum (not XOR) of the other 7 nibbles. The 1st and 3rd nibble of the fixed data are decomposed from one of the two device number. So the RM approach is quite difficult to use, if the user is starting from DecodeIR.dll generated data.

In my opinion, which is surely influenced by the comments of others, is that RM should accept 2 device numbers (and a byte and nibble of "OEM code", which appear to be invariant in nearly all examples seen so far) and calculate the fixed data including the checksum nibble. That would require a new entry to protocols.ini (easy) and a new translator class that can calculate the checksum nibble for XMP fixed data.

I've been reluctant to ask for such a modification to RM, because the present approach is workable, although I suspect very confusing to most users. But from mathdon's above comment, it appears that any user (for example, me) can write the new entry to protocols.ini and the new class, and then distribute just those items to other interested users, without disturbing the development of RM. If that's the case, I'll volunteer to try (with no warranty of success).

How do we as a community decide the implementation of such a translator? It seems to me that one could make a translator (XMPXlator.class) that is aimed at XMP only, or make a translator (NibbleSumXlator.class) that is more general in application. Or does it matter?

This latter part of this thread illustrates the motivation for wanting to make a change.
Back to top
View user's profile Send private message
mr_d_p_gumby
Expert


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

                    
PostPosted: Sat Jan 02, 2010 1:19 pm    Post subject: Re: Dreambox/XMP protocol Reply with quote

3FG wrote:
How do we as a community decide the implementation of such a translator?
Normally, this is not such a complex question. Aside from those cases where Robman decides he wants it done a certain way, Greg & I usually try to follow John's (and now Graham's) DecodeIR logic as much as possible. However, it's not always easy to translate DecodeIR output into the data needed by a given UEI executor.

XMP has been particularly difficult because several attempts at implementing it manually were inconsistent. Robman has suggested we implement it as two protocols (XMP-1 and XMP-2) where -1 puts the OBC in the first variable byte and -2 puts it in the second. (Of course, as soon as we do that, then we'll find something that uses both bytes!) Adding to the problem is that the Slingbox timing is off and it can't accept a device/protocol upgrade as large as the standard XMP, so we also need to create actual XMP-1 and XMP-2 protocols for use in such upgrades, yet still revert to the built-in protocol for other remotes.

I've been experimenting with various implementations in KM, and so far it looks like I will probably have three choices: XMP, XMP-1 and XMP-2. They would all use the same fixed data construction, but differ in how they define the variable bytes. XMP would always be a two-byte protocol, and XMP-1 and XMP-2 would be one-byte versions using (yet to be created) JP1 custom protocol executors. I'm still trying to work out how to provide a different executor for the Slingboxes (for timing correction), and I'm not sure how you would do that in RM either.
_________________
Mike England
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Sat Jan 02, 2010 2:45 pm    Post subject: Reply with quote

I recently started playing with the XMP protocol. I'd like to get caught up with the rest of you, and this seems to be as good a place as any.

mr_d_p_gumby wrote:
However, it's not always easy to translate DecodeIR output into the data needed by a given UEI executor.


The only valid XMP signals I have seen came out of decodeIR with a nice device, subdevice OBC. However when I was playing with KM and RM trying to figure out how to feed that information into a device upgrade the resulting decode had a huge OBC, because the obc info needed to be in the Subdevice, not into the OBC. From what Mike just said about the need for XMP1 XMP2 it sounds like that attrocious OBC information would have been correct for some XMP signals.

Is that what you meant by this not being easy to translate?

Or are we talking about the bad learns of this protocol, translating into nonsense because there are too many timing pairs in the signal for the learning remote to use?

Or are we talking about DecodeIR's device/subdevice not being reflective of the 4 bytes of fixed data in the XMP protcol?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Jan 02, 2010 3:12 pm    Post subject: Reply with quote

Well, I was thinking of just implementing a translator which would correctly calculate the arithmetic checksum. Here's the Dreambox entry in protocols.ini (minus the actual protocol upgrade code):
Code:

[Dreambox]
PID=01 6C
DevParms=Device=18,OEM Dev1=6,OEM Dev2=15,OEM Dev3=68
DeviceTranslator=Translator(1,8,0) \
                 Translator(2,8,8) \
                 Translator(3,8,16) \
                 Translator(0,8,24)
FixedData=06 0F 44 12
CmdParms=OBC=0,Sub Device=0
CmdTranslator=Translator(1,8,0) Translator(0,8,8)
CmdIndex=1
DefaultCmd=00 00


I believe that the various XMP-1, XMP-2. and XMP protocols don't require a new CmdTranslator implementation, just a slightly different entry.

However, we do need a new DevTranslator to implement the arithmetic checksum. My thought was to simply change the DevParams and DeviceTranslator lines in order to bring the device nomenclature into line with DecodeIR and to reference the new class. I'd also change change the CmdParms to show labels OBC-1 and OBC-2. For XMP, the user would enter the two bytes of variable data into those two columns. For XMP-1, the user would enter the OBC value into OBC-1, and zeros (or nothing) into OBC-2.

We could also define (now or later) separate XMP-1 and XMP-2 protocols without disturbing the above XMP protocol. These would have a single OBC heading. For RM, perhaps the syntax of protocols.ini would allow us have a single XMP protocol, with check boxes to indicate the choice of XMP-1, XMP-2, or XMP, but I think it would be much simpler to define 3 separate protocols, especially if different executors are used to save space.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Jan 02, 2010 3:31 pm    Post subject: Reply with quote

3FG wrote:
In another thread mathdon wrote:
Quote:

I have discovered that WinZip is capable of adding new Java class files into a .jar file, so given the Grundig16 entry for the text file protocols.ini and the compiled GrundigXlator.class file, users of RemoteMaster can then add this protocol themselves if they wish.

Do I understand this correctly? Is this applicable to the Dreambox/XMP situation, where RM usage of device numbers differs from DecodeIR.dll?

I believe you are understanding correctly. My experiments with Grundig16 suggest that anyone can add a new protocol to RM, even if it needs a new translator, provided they are supplied with the protocols.ini entry and the class file for the Java translator. It also suggests that neither of these is particularly difficult to construct. But what seems of paramount importance to me is that doing this does not interfere with the normal development of RM in the slightest, as nothing needs to be modified (other, of course, than the addition to protocols.ini) and the additions have no dependence on the version of RM to which they are being added.
___________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Sat Jan 02, 2010 9:03 pm    Post subject: Reply with quote

Just FYI, UEI has started putting zeroes in the checksum nibble of the fixed data because they've added logic to their executor to calculate the checksum for the fixed data also. This is primarily for Vicky's benefit in case she notices differences between the fixed data in an old upgrade vs. a new upgrade, where the only difference is the checksum nibble.

Of course, if we are going to provide a protocol upgrade to the user, we could eliminate this code if we are going to have KM/RM calculate the checksum nibble.

And for what it's worth, I agree with having 3 versions of XMP. At present, there are no remotes that I know of that have the XMP executor pre-installed, but this will change as it is a UEI protocol. If a remote has the official version installed, it would be better to use it and create a device upgrade with 2 variable bytes, but if the remote does not have it installed, it would be better to use a modified version of the executor that only requires one variable byte.

If we want to be super flexible, we could add a flag to the fixed data that would indicate which byte is the OBC byte, that way if a user just happens to need to use two XMP upgrades where the OBC bytes are different they wouldn't be forced to chose between adding the protocol twice or using 2 variable bytes.

As for the question of what do we do if a device comes along that uses both OBC bytes, while I don't think that's likely, if it does happen, we would need to use the original UEI executor.
_________________
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
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sat Jan 02, 2010 10:54 pm    Post subject: Reply with quote

The Robman wrote:

Just FYI, UEI has started putting zeroes in the checksum nibble of the fixed data because they've added logic to their executor to calculate the checksum for the fixed data also.

and later in the same post....

At present, there are no remotes that I know of that have the XMP executor pre-installed, but this will change as it is a UEI protocol.


I'm not sure what this means. The second part of quote seems to say that UEI remotes don't currently have a XMP executor, but quite a few UEI manufactured remotes are able to shoot XMP natively, as can be seen in the Lookup Tool. And the first part of the quote seems to imply they do have an executor.

Are you suggesting that we don't compute the checksum and put it in the fixed data? That would seem to carry the risk that older remotes would become broken.
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Sat Jan 02, 2010 11:42 pm    Post subject: Reply with quote

The last time I put data together for the devices.xls spreadsheet there weren't any remotes that have the official UEI executor built into them. That doesn't mean that there isn't an official UEI executor, which there obviously is as it's a UEI protocol.

My point is that, in most cases, the user would need to add the protocol to their remote in order to work an XMP controlled device, so I'm suggesting ways that we can reduce the size of the upgrade that they need to load.

The official UEI executor uses 2 variable bytes, in order to handle both formats (ie, it can handle when the device uses OBC1 or OBC2). The draw back of this is that the device upgrade is twice the size as each button needs 2 bytes of hex data (where one byte is always zero).

I don't recall if the early versions of the UEI executor calculate the fixed data checksum, but I do know that UEI used to always put the correct data in the checksum spot of the fixed data. This has changed as they now put zeroes in this spot, knowing that the executor will calculate it.

Obviously, having the executor calculate the fixed data checksum requires extra code in the executor, which is not needed if the fixed data is calculated correctly in advance. I'm not sure what your concern about "older remotes" is, but hopefully that has answered that question.

While I'm not aware of any JP1 remotes that have the XMP executor built in, there will undoubtedly be some that do sooner or later (and your post seems to imply that you already know of some). For these remotes it would be more memory efficient to use 2 bytes of variable data and not include a protocol upgrade.
_________________
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
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sun Jan 03, 2010 12:46 am    Post subject: Reply with quote

OK, I'm confused. Devices.xls has a file date of 3/31/09. It lists 35 setup codes which are described as XMP protocol, pid 016C.

Remotes which have at least one of these are 15-100, 15-135, URC-7525, 7555,7780,7781, 7820(JP1.3), 7950, 8040, 8203, 8206, 8210, Atlas 3000, 3033, Comcast 1067, 167BX3, Cricket, Dreambox 1038, Slingbox JU, PL, PK, RV, Vizio VUR8. The Lookup Tool adds the URC-7940, 8050, 8350, 8820/10820N, RCRP05B.

At our house, we have a Comcast 1067BX3 in use which controls a Pace DC50X (Comcast DTA ) using setup code C1982.

So, my concern is that one of these remotes, which seem to date back to 2006, will have an built-in executor which depends on the checksum being in the fixed data. I'll try to test one of my 15-135, Comcast, or RCRP05B remotes to see the effect of feeding it a zero checksum nibble.

Edited to Add: I did check the Comcast 1067BX3 starting with the same fixed data as C1982. After changing the 2nd nibble from 7 to 0, the remote still controlled the Pace DC50X. I learned the signals, and either value in the 2nd nibble gave identical decodes.

At least for this remote, there is no need to send the checksum to the official executor. So I'll start by only making a XMP entry for protocols.ini.
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Sun Jan 03, 2010 8:27 am    Post subject: Reply with quote

IF I sent the correct information from my home computer, there are no 016C variations noted in the current RDF's nor any new variants identified for the next RDF release.

What does it take to qualify as a new variant? I've been told somewhere, that XMP executors have different Pause times, off times. I am having trouble finding that information, but is timing alone enough to qualify as a new variant, or is it the treatment of these variables that might need to be precalculated that qualifies it as a new variant?

There have been so many XMP threads in the past 2 weeks that I feel that I can't ignore it anymore. However going from a basic understanding of binary codes, to a hex based code is quite confusing!

I don't quite grasp all the implications of the various solutions being proposed here but I can see that making bad choices now will haunt the boards for a long time.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
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: Sun Jan 03, 2010 12:00 pm    Post subject: Reply with quote

vickyg2003 wrote:
IF I sent the correct information from my home computer, there are no 016C variations noted in the current RDF's nor any new variants identified for the next RDF release.
According to my data, there are 5 S3C8 and 4 HCS08 versions of 016C in various remotes that I've examined. All of them calculate the checksum and ignore anything pre-calculated in the fixed data. All of them use essentially the same timing.

The primary reason for identifying variants of UEI executors in the RDF files is to make sure the JP1 tools construct the fixed and variable data in a manner that is compatible with the requirements of the executor. Sometimes this means a different number of fixed and/or variable bytes, and other times it means the existing bytes can control additional fuctionality (example: the newer Pioneer MIX variants).

In the case of the XMP executors, so far I have not been able to detect any difference in the fixed or variable data used by any of the variations, so there is presently no need to identify variants. There are some subtle differences. For example, the latest S3C8 & HCS08 versions add a forced repeat of 14x if it is executing within a macro. The other differences just seem to be attempts to re-code this rather huge executor more efficiently.

The Robman wrote:
If we want to be super flexible, we could add a flag to the fixed data that would indicate which byte is the OBC byte, that way if a user just happens to need to use two XMP upgrades where the OBC bytes are different they wouldn't be forced to chose between adding the protocol twice or using 2 variable bytes.
I was thinking along similar lines, mainly that XMP-1 and XMP-2 would use the same executor, and a bit in the fixed data would control the OBC-1 and OBC-2 decision. If the executor still does the checksum, then 4 bits are unused in the existing fixed data.

BTW, can you give me any idea of how small the executor needs to be for the Slingboxes? Do you have any hunches on how the timing differs?
_________________
Mike England
Back to top
View user's profile Send private message
The Robman
Site Owner


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

                    
PostPosted: Sun Jan 03, 2010 4:17 pm    Post subject: Reply with quote

I guess I must have been thinking of another protocol when I said that. I'm on a new computer so I don't have any JP1 files here and I haven't installed MS Office yet either, so I can't look at spreadsheets yet.

Anyway, as I said earlier, UEI always used to calculate the checksum nibble correctly when they formatted the fixed data, and we've always done so too (though it's not automated yet). I was not suggesting that we stop formatting the checksum nibble, I was suggesting that we delete the logic from the protocol upgrade that does it, as it's not needed when it's been properly formatted in advance. So I think you got my suggestion backwards. Furthermore, this would only apply for remotes that don't have the XMP protocol pre-installed, so the "older remotes" argument still doesn't apply.

Of course, if we decide to use the checksum nibble as a switch to alternate between XMP1 and XMP2 formats, we would need to keep the checksum logic in the executor.

I believe the Slingbox has a size limit of about 200 bytes, that's total for the upgrade (including the device upgrade and protocol upgrade). So, when I create XMP upgrades for the Slingbox, I create an executor that uses 1 variable byte, then I jump to the actual executor in the Slingbox so that I don't have to repeat all the logic in my executor.
_________________
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
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
Page 1 of 10

 
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