Hello, I have managed to find out protocol / freq etc & create full panels of buttons using the utils IRTool, MakeHex & IRPanels, with help from the always helpfull johnsfine and Lyndel McGee. Now, as I move through my devices, setting them up, I hit another hurdle (or 2)

Question1 - How do I determine Device / Protocol etc for a learned code of ...
900A 0068 0000 0001 866B 45BA
... IRTool states "The HEX code is not a learned code. IRTool only works with Learned codes." This prevents me from generating all OBCs in IRTool, since i dont know details.

This code was learned, however, i suspect ProntoEdit has converted it to some internal format.


Question2 -

Who would I need to contact to suggest improvements / bug fixes for pronto edit? I have been working with this util now for 2 weeks & I must say, there is work to be done. Some very annoying 'features', short commings & bad design realy make me want to bash my laptop (though i won't)!
Pehaps someone knows of a forum that Pronto edit developers would read / heed suggestions for improvments & fixes. Or perhaps, I / Someone here could start a thread asking users what improvements / features / fixes they would like to see & then we could pass this on to prontoedit devs?

Any thoughts?


PS, If Pronto Edit Devs read this, don't take offense, I do like you application, Its just the little things, you know like, size of the properties box, unable to copy/paste macro entries, no left / right alignment tools, no 'rubber band' selection of items, lack of short cuts, lack of 'Quick Test IR HEX', unable to drag buttons into gallery (the import option is very poor on the gallery, only 1 item at a time & it resets back to root every time!) etc etc


Using Pronto Edit NG build 2, 0, 6, 0

SD00,

You should be able to multi-select items to import into the Gallery, just like a Windows multi-select. Ctrl + Click for individual items and Shit+click for a whole area of items.

Dave D'Arche

0000 0068 0022 0002 0188 00BB 0017 0017 0017 0046 0017 0046 0017 0017 0017 0017 0017 0017 0017 0017 0017 0046 0017 0046 0017 0046 0017 0017 0017 0046 0017 0017 0017 0046 0017 0046 0017 0017 0017 0046 0017 0017 0017 0046 0017 0017 0017 0017 0017 0017 0017 0046 0017 0017 0017 0017 0017 0046 0017 0017 0017 0046 0017 0046 0017 0046 0017 0017 0017 0046 0017 0675 0188 005D 0017 0F7F

900A always indicates NEC1. The device is in the position where the 86 is in that example, the subdevice where the 6B is and the OBC where the 45 is. All the rest can be ignored.

86 hex is 134 decimal
6B hex is 107 decimal
45 hex is 69 decimal

So the whole thing is NEC1:134.107:69

Dave's translation to 0000 format is correct and would let you get the answer for this one sample from IrTool. I hope my answer lets you understand all 900A format codes.

The non-JP1 version of IrTool doesn't use the "subdevice" terminology. It calls this device number 27526 rather than 134.107.

To get that from the 866B in the original sample, you must reverse the halves to get 6B86, then convert from hex to decimal.

Thanks dave. but how (if you don't mind me asking).

But damn, something odd happend here!

The pronto took a long time to learn that one i 1st gave you. When i tried yours, it did not power off my thomson hifi. Nor did the learned code either! So i learned it again & it still didn't work. So I tried a quick short tap of the original remote - IT WORKED! ODD. the code it learned this time was...
0000 0068 0026 0000 0164 00B4 0016 0016 0016 0043 0016 0043 0016 0016 0016 0016 0016 0016 0016 0016 0016 0043 0016 0043 0016 0043 0016 0016 0016 0043 0016 0016 0016 0043 0016 0043 0016 0016 0016 0016 0016 0016 0016 0043 0016 0043 0016 0043 0016 0016 0016 0016 0016 0016 0015 0043 0016 0043 0016 0016 0016 0016 0016 0016 0016 0043 0016 0043 0016 0043 0016 062D 0164 005A 0016 0EF5 0164 005A 0016 00B4
Which according to IRTool & DecodeIR is an NEC1 134.107 I have now managed - thanks Dave.

Question remains though, how?

[EDIT] John has provided an answer, thanks all the same. [/EDIT]

Cheers Steve Mac

This message was edited by sd00 on 09/26/04 18:08 ET.

It don't work for me :(

Thanks john, I'll study that.

Ah i see,
134=86
107=6b
6b86 = 27526

So then i use this number in JP1 forums for further info on the device? or is there some other relevance (bear with me, i'm trying to grasp it all)

I don't understand this question.

If you did want to discuss that signals in the JP1 forum then NEC1:134.107:69 is a concise way to describle it that would be understood by most people there, including many who wouldn't understand "900A 0068 0000 0001 866B 45BA" (Though of course most experts in JP1 understand it either way). Why did you want to discuss it in the JP1 forum (when you're also asking about ProntoEdit enhancements).

If you were using MakeHex to generate all the other signals with the same protocol, device and subdevice then that would be another reason to want the signal in that form.

Despite having had a recent disagreement with Dave about exactly this subject, I completely ignored an important detail this time. (Until you helped my memory with the above statement).

This signal has the structure I'm calling "NEC1" but it has a higher modulation frequency.

When the Pronto or ProntoEdit recognises the NEC1 pattern it translates to the 900A format. It does that similarly for a well learned signal or for a paste of a perfect signal (such as the one Dave gave you).

In translating to 900A format it retains the correct higher frequency.

BUT when it actually uses the 900A signal it ignores the higher frequency specified and sends the IR at the nominal NEC1 frequency. That's why it doesn't work.

When the signal gets learned badly, the Pronto doesn't see the pattern and doesn't translate to 900A format, so it doesn't know what the nominal frequency should be, so when it transmits the signal it uses whatever frequency it saw when it learned the signal rather than "correcting" the signal to match nominal. That's why it works.

In another thread I made an intentionally slightly distorted version of the nec1.irp file so I could generate nearly perfect signals in 0000 format there were far enough from perfect to "confuse" PENG into not translating to 900A format, but closer to perfect than you'd get from an intentionally bad learn.

Sorry john, I thought there was some relevance ~ something i was missing ~ when you said "The non-JP1 version of IrTool doesn't use the "subdevice" terminology. It calls this device number 27526 rather than 134.107"

I assume now it was for information purposes only.

As for the Pronto Edit enhancements, it was in my head & i had to get it onto 'paper'.

I'm still putting the peices together. I'd like to have a thourough understanding ~ its just the way i work! I need to fully understand thing before it all fits. I know you could point me to piles of documentation, but for the time being, i'm splitting my time with getting my control operational & learning the lingo, work, wife, children, ......

Thanks for you time and effort (everyone). Steve Mac.

Applied Digital (makers of the Ocelot) tell me they have little problem as long as the carrier is ±5kHz of nominal. Nirvis (makers of the Slink-e) say ±2kHz is OK.

My own experience (I designed PDA-ir which was a CF card IR extender for iPAQs, etc.) is that the wavelength of the IR emitter is far more critical than the carrier frequency. The people who manufactured PDA-ir did 100% testing and all of them operated a target TV at 97-100 feet. That was with one 940nm IR emitter driven by ~3V.

Griffin Technology's Total Remote dongle plugs into the headphone jack of a PDA. They send bursts of about 16-18kHz and use two emitters in a full wave rectifier configuration to double the effective carrier frequency. They claim 100+ foot range.

I doubt that a 2kHz error in the carrier frequency will make the difference between a code working and not working although it will affect the range at which it works.

I doubt that the bandpass filters used in the IR receiver modules are all that narrow. The datasheets usually have curves that show reasonably good response at ±5% of the center frequency. And, almost all protocols can handle ±10% deviation from nominal time intervals.

Dave Houston
CodeGenPro™

I gave an answer assuming you were using the JP1 version of IrTool then I noticed that I couldn't tell which version you were using, so I immediately edited my message to give the other version of the answer as well.

That sounds like you don't agree that the 2kHz difference is the reason in this thread that the two clean versions were reported as failing but the less clean version worked.

Is that right? Do you have another theory for what worked vs. didn't work in this thread (and the other thread where we had a related disagreement)?

Or does range explain it? He happened to test from a range where the 2kHz difference mattered?

I'm well aware that a 2kHz difference typically doesn't matter. I doubt many IR receivers still use analog band pass nor any digital process that drops off similar to an analog band pass. Most digital filtering tends to be a lot closer to ideal filtering, so it would tend to just work or not work rather than reduce range.

Overall, I try to bend the theory to fit the reported results. Theory says 2kHz frequency difference is too small to wreck the signal. Reported results in this and that other thread say the 2kHz difference is critical. So I bend the theory to guess that someone put unusually picky digitial filtering into the IR receiver of this particular device.

edit: accidentally got one post too many here

||

That's one theory. Another is that the Pronto NG mangles codes with no rhyme nor reason.