On May 10, 2009 at 08:09, johnsfine said...
My best guess is that the MX editor somehow recognizes a repeating pattern and removes the excess when you import Pronto Hex
Your results seem to be supporting that guess.
On May 10, 2009 at 14:05, hdtvluvr said...
Then I tried the version in your last post. It changes the volume by 2 db. This is getting closer to what I need. Any idea how to add sections to get the additional 1 db?
Just add more sections and keep varying the delay value.
If I am reading your latest version correctly, you are adding the last 4 words to the body 8 times - changing the red number
0000 006D 0032 0002 0155 00AA 0015 0015 0015 0040 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0015 0015 0040 0015 0015 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0040 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 05ED 0155 0055 0015
0C00 0155 0055 0015 0E00 0155 0055 0015 0C00 0155 0055 0015 1000 0155 0055 0015 0C00 0155 0055 0015 1000 0155 0055 0015 0E00 0155 0055 0015 0C00 0155 0055 0015 0E00
Notice the delay values (the ones now in red). I added eight copies of the repeat chunk, but not eight identical copies. I made three different versions and added them in a non repeating sequence.
I was guessing that the MX editor looks for repeating patterns in the non repeating part of the data and throws them away. So I changed the pattern just to confuse it, so it wouldn't throw anything away. Probably it has a simple enough pattern detector that I didn't need to change nearly as far, nor vary the change in such a complex way. But I wanted to be sure I had the best chance to fool that pattern detector.
Your other test results seem to indicate changing the delay a lot (up to 1C00 or down to 0700) makes a difference and annoyingly in either direction it makes things worse. It is still possible a smaller change would make it better rather than worse. But that doesn't seem to be the best line of investigation.
The small change (up to 1000 and down to 0C00) that apparently fools the pattern detector in the MX editor apparently doesn't make anything much worse. Probably it makes no significant difference in the remote or in the actual device and it just serves its intended purpose of fooling the editor.
I'm pretty sure values very close together, such as 0E46, 0E47 and 0E48 would all be treated as the same value by the MX editor, so they couldn't fool that pattern detector. Your test results confirm my estimate that 0C00, 0E00 and 1000 are far enough apart to not be treated as the same number.
You might want to check whether a small difference would have been enough, such as 0E07, 0E47 and 0E87. I suspect those aren't far enough apart, but I'm not sure.
Last edited by johnsfine on May 10, 2009 14:52.
