Hi,

I'm developing a Java Application to act as GUI for 1994 and C7 (and
possibly other remotes like 1925).

So far I'm able to interpret memory dump as mentioned in Rob's site ,
able to add/modify individual items and have following questions and
looking for help.

1. Adcanced Code / Macro section.
       How to interpret 3rd byte (3/4 byte is Device Code). I'm using
Sony Misc Audio code 159 to analyze this.

Here's Advanced Code sequence in question.
34  83  40  9f  de

34 - Arrow Right (key)
83 -
       8 - AUX1
       3 - 1 Byte Command

40 - What is it and how to interpret? Where can I find more info?

9F - Misc. Audio code 159 (for Sony)
DE - Advanced Code (from OFA list)

2. Learned Code
  There appears to be some no. of bytes AFTER Last Learned Code. What
is it? Or Can I ignore that? (Is it the result of some erased Learned
keys?)

3. And finally, I'm a bit confused about 'Protocols' tab of nice
application IR.exe, where it shows byte dump. I can not find it in my
original Memory Dump. What is it?

TIA,

Bandhan

Rob,

Thank you very much for offering help in making my 1994 and C7
perfact remotes.

It worked with VCR as device and 0715 as code.

I was using my pre-Alpha stage Java program to interpret/patch memory
dump (as per guide lines mentioned in your website). I promise to
make it available online as soon as it is in presentable format.(More
Info. and questions on this in a new thread :-)

I should have used disdump, to figure this out.

Thanks
Bandhan


--- In jp1@egroups.com, "Rob Crowe" <rob@r...> wrote:
> You don't need to patch the checksum as the software takes care of
that for
> you.  At this stage in the works it's probably easiest if you just
tell me
> what device codes you need and I'll create them for you.

> From larss@... Thu Dec 28 17:56:07 2000
>
> Well, I finally got the time to build one of these boxes, and it
> works (sort of). I have a few problems:
>
> First:
> For some reason I cannot get it to work properly on my PIII/450. The
> download (remoteif -dump) does not complain, but only downloads the
> first 400 bytes (approximately) properly, the rest just shows as
> ff. The upload (remoteif -load) always gives and error (errno 5)
> when trying to upload to the remote. It does work on my old
> Pentium/166 though. It is somewhat of a pain using this machine
> since I'm using this as a firewall, running Linux. The MS win
> installation on this machine is extremely unstable, it'll only run
> for 5-15 minutes before crashing. I had planned to claim the disk
> space on this machine for other use, but now I guess I'll wait until
> I can find another machine this will work on. Wasn't the initial SW
> that Dan wrote for Linux, if so is that still
> available/functional/up-to-date? That would really help me out. I
> did also try using a Win2K machine, but on this machine the remoteif
> program just crashes (probably because of access rights).


Oh boy, sounds like a timing problem.  Make sure the wires on the remote
side (between JP1 and IC1) are 6 inches or shorter.  If you have a shorter
printer cable (3ft or less), try using that.

This problem has come up before, so I may have to write a diagnostic
program that you would run to measure the I/O speed of the chipset.
Some of the timing values in remoteif probably need to be adjusted to
work with a wider range of hardware.


> Second:
> There seems to be a problem in disdump/asmdump. The best way to
> explain this is probably to explain the steps I go through:
> 1. Download dumpfile from remote: remoteif -dump dump.txt
> 2. Convert using disdump: disdump dump.txt > disdump.txt
> 3. Edit disdump.txt to add the Replay codes, save as disdump1.txt
> 4. Convert using asmdump: asmdump disdump1.txt > newdump.txt
> 5. Verify conversion using dispdump: disdump newdump.txt > disdump2.txt
>
> After this you would think that disdump1.txt and disdump2.txt should be
identical, but they are not, the only difference is in the Advanced codes &
macros section:
>
> disdump1.txt:
>
> Advanced codes & macros:
>   2f  03  01  dc  9c
>
> disdump2.txt:
>
> Advanced codes & macros:
>   ff  2f  03  01  dc  9c  30  03  01  dc  1c  35  03  01  dc  dc


While the current version of disdump supports several remotes, the
current version of asmdump only supports the RS15-1994 remote.
Different remotes put the data structures in different places.  I'll
update asmdump to handle this (in a few days).


> Lastly, I just have to congratulate Dan & Rob on a job well done,
> I'm hopeful I'll be able to convert my C7 into the perfect remote
> real soon now.

You might be the first person to seriously use the hw/sw on the C7,
so you'll probably be the first to encounter problems like these.
Let us know what else you find.

________________________________________________________________________
Daniel H. Nelsen                                email:  dhn@...
PMC-Sierra MIPS Processor Division
Santa Clara, CA
________________________________________________________________________

> From gwilliams@... Thu Dec 28 19:47:32 2000
>
> I completed my "box" and set out to test it. Being that all three of
> my boxes run NT, I created a DOS 6.22 boot disk and copied the
> remoteif file to the boot disk. I booted my machine into DOS. Trying
> to run remoteif I received the error that it would not run in DOS
> mode? Shouldn't it run under a DOS only machine?


The executable was compiled with mingw (native Windows port of GCC
available free from www.mingw.org) and requires the Windows dll
msvcrt.dll.  That's why the executables are so small.

To run under native DOS, you'll have to compile the source using djgpp
(native DOS port of GCC available free from www.delorie.com), or any
commercial compiler that can produce a pure DOS executable.

________________________________________________________________________
Daniel H. Nelsen                                email:  dhn@...
PMC-Sierra MIPS Processor Division
Santa Clara, CA
________________________________________________________________________

I completed my "box" and set out to test it. Being that all three of
my boxes run NT, I created a DOS 6.22 boot disk and copied the
remoteif file to the boot disk. I booted my machine into DOS. Trying
to run remoteif I received the error that it would not run in DOS
mode? Shouldn't it run under a DOS only machine?

Greg

Well, I finally got the time to build one of these boxes, and it works (sort
of). I have a few problems:

First:
For some reason I cannot get it to work properly on my PIII/450. The download
(remoteif -dump) does not complain, but only downloads the first 400 bytes
(approximately) properly, the rest just shows as ff. The upload (remoteif -load)
always gives and error (errno 5) when trying to upload to the remote. It does
work on my old Pentium/166 though. It is somewhat of a pain using this machine
since I'm using this as a firewall, running Linux. The MS win installation on
this machine is extremely unstable, it'll only run for 5-15 minutes before
crashing. I had planned to claim the disk space on this machine for other use,
but now I guess I'll wait until I can find another machine this will work on.
Wasn't the initial SW that Dan wrote for Linux, if so is that still
available/functional/up-to-date? That would really help me out. I did also try
using a Win2K machine, but on this machine the remoteif program just crashes
(probably because of access rights).

Second:
There seems to be a problem in disdump/asmdump. The best way to explain this is
probably to explain the steps I go through:
1. Download dumpfile from remote: remoteif -dump dump.txt
2. Convert using disdump: disdump dump.txt > disdump.txt
3. Edit disdump.txt to add the Replay codes, save as disdump1.txt
4. Convert using asmdump: asmdump disdump1.txt > newdump.txt
5. Verify conversion using dispdump: disdump newdump.txt > disdump2.txt

After this you would think that disdump1.txt and disdump2.txt should be
identical, but they are not, the only difference is in the Advanced codes &
macros section:

disdump1.txt:

Advanced codes & macros:
   2f  03  01  dc  9c
   30  03  01  dc  1c
   35  03  01  dc  dc
   36  03  01  dc  5c
End (advanced codes & macros)

disdump2.txt:

Advanced codes & macros:
   ff  2f  03  01  dc  9c  30  03  01  dc  1c  35  03  01  dc  dc
   36
   03  01  dc
   5c  00
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
   ff
   ff  ff  ff  ff  01  d6  01  dc  92  00  fe  fe  fe  f9  e0  01
   00
End (advanced codes & macros)

I'm not sure if this is really a problem or not, since downloading the file from
step 4 above does seem to work (although since I'm using a C7 the replay does
not work quite right, as Rob had already warned me).

Third:

On Rob's website (at http://www.rockabilly.net/hack/upgrade.shtml) it lists the
device codes for the C7 as:
3-cd, 5-vcr

From initial playing around with this a bit it seems my C7 uses these device
codes:
3-vcr, 5-cd


Anyway, I just completed the HW today, and haven't really played around with it
enough, but any help for the problems above would be appreciated (especially #1
since the constant rebooting is really time consuming).

Lastly, I just have to congratulate Dan & Rob on a job well done, I'm hopeful
I'll be able to convert my C7 into the perfect remote real soon now.

-lars

You don't need to patch the checksum as the software takes care of that for
you.  At this stage in the works it's probably easiest if you just tell me
what device codes you need and I'll create them for you.

----- Original Message -----
From: <bgadani@...>
To: <jp1@egroups.com>
Sent: Thursday, December 28, 2000 4:21 PM
Subject: [jp1] Re: Which is best remote to accompany 1994 ( for upgrading
1994 to new codes)


> How to use this once I've uploaded to 1994 (and patched Checksum)?
>
> What is Device/code combination

How to use this once I've uploaded to 1994 (and patched Checksum)?

What is Device/code combination?

--- In jp1@egroups.com, "Rob Crowe" <rob@r...> wrote:
> The 15-1925 might actually be your only choice for doing what you
want as
> it's the only US remote that I know of that has the internal modem
and the
> 6-pin connector, but you should be aware that if the device code in
question
> uses a new protocol, the protocol code cannot be copied from the 15-
1925 to
> the 15-1994.
>
> At any rate, even with this remote you'll only be able to download
device
> codes that UEIC have seen fit to make, and they haven't made a code
for the
> Raite yet.  But fear not, I also have the Raite and I've made a
code for it
> already, here it is....
>
> 100:  01  3d  01  43  5a  00  fe  fe  fe  fe  ff  20  fb  04  6D  37
> 110:  F7  77  0F  CF  4F  2F  EF  6F  55  57  3f  65  67  8f  4d  17
> 120:  bf  9f  7d  dd  47  c7  ed  c5  cd  87  e5  d5  fd  c5  45  27
> 130:  e7  75  07  a7  97  D7  AF  B7  F5  7F  ab  aa  a9  00  01  22
> 140:  cb  01  04  00  00  00  00  00  00  00  00  00  00  00  00  00
>
>
> Later,
> Rob.
> ----- Original Message -----
> From: <bgadani@h...>
> To: <jp1@egroups.com>
> Sent: Wednesday, December 27, 2000 10:35 AM
> Subject: [jp1] Which is best remote to accompany 1994 ( for
upgrading 1994
> to new codes)
>
>
> > Hi,
> >
> > I have access to RS 19-1925 (Old 6in1 IR/RF remote ). (I can buy
it)
> >
> > Here's what I'm trying to do.
> >
> > Get Upgrade codes via phone into RS 19-1925.
> > Dump it to file.
> > Download (probably after some sort of conversion) it to 1994.
> >
> >
> > I'm particularley interested in Upgrade code for Raite DVD player.
> >
> >
> > I'm looking for suggestions as to
> > 1) It is good to keep/buy OLD RS upgradeable remote. and
> > 2) which Old RS remote I should buy for this purpose?
> >
> > Thanks
> >
> > Bandhan
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > jp1-unsubscribe@egroups.com
> >
> >

I've got the rest of the key mapping done for the other modes.

http://www.hifi-remote.com/hack/keymap.shtml

The 15-1925 might actually be your only choice for doing what you want as
it's the only US remote that I know of that has the internal modem and the
6-pin connector, but you should be aware that if the device code in question
uses a new protocol, the protocol code cannot be copied from the 15-1925 to
the 15-1994.

At any rate, even with this remote you'll only be able to download device
codes that UEIC have seen fit to make, and they haven't made a code for the
Raite yet.  But fear not, I also have the Raite and I've made a code for it
already, here it is....

100:  01  3d  01  43  5a  00  fe  fe  fe  fe  ff  20  fb  04  6D  37
110:  F7  77  0F  CF  4F  2F  EF  6F  55  57  3f  65  67  8f  4d  17
120:  bf  9f  7d  dd  47  c7  ed  c5  cd  87  e5  d5  fd  c5  45  27
130:  e7  75  07  a7  97  D7  AF  B7  F5  7F  ab  aa  a9  00  01  22
140:  cb  01  04  00  00  00  00  00  00  00  00  00  00  00  00  00


Later,
Rob.
----- Original Message -----
From: <bgadani@...>
To: <jp1@egroups.com>
Sent: Wednesday, December 27, 2000 10:35 AM
Subject: [jp1] Which is best remote to accompany 1994 ( for upgrading 1994
to new codes)


> Hi,
>
> I have access to RS 19-1925 (Old 6in1 IR/RF remote ). (I can buy it)
>
> Here's what I'm trying to do.
>
> Get Upgrade codes via phone into RS 19-1925.
> Dump it to file.
> Download (probably after some sort of conversion) it to 1994.
>
>
> I'm particularley interested in Upgrade code for Raite DVD player.
>
>
> I'm looking for suggestions as to
> 1) It is good to keep/buy OLD RS upgradeable remote. and
> 2) which Old RS remote I should buy for this purpose?
>
> Thanks
>
> Bandhan
>
>
>
> To unsubscribe from this group, send an email to:
> jp1-unsubscribe@egroups.com
>
>

Hi,

I have access to RS 19-1925 (Old 6in1 IR/RF remote ). (I can buy it)

Here's what I'm trying to do.

Get Upgrade codes via phone into RS 19-1925.
Dump it to file.
Download (probably after some sort of conversion) it to 1994.


I'm particularley interested in Upgrade code for Raite DVD player.


I'm looking for suggestions as to
1) It is good to keep/buy OLD RS upgradeable remote. and
2) which Old RS remote I should buy for this purpose?

Thanks

Bandhan

Hey Gang,
I decided to go ahead and decode the key mapping bytes, these are the 3 or 4
bytes that appear starting at byte three of an upgraded device code, they
tell the remote which buttons are to be mapped out for this new device.

I have just finished testing these codes using VCR mode and have posted them
on my site.  The results will be different in the other modes, so once I
have done them too I will add them.

The results are at http://www.hifi-remote.com/hack/keymap.shtml

Later,
Rob.
http://www.hifi-remote.com/hack

I forget who sent the original message as it's on my work email, but
somebody said that they had managed to get the volume punch through to
program the volume buttons in all modes except P&P.  I can only get the
volume punch through to program the volume buttons in TV, VCR and CABLE
mode.

So, could I see a dump of the memory to see how it is set please?

Rob.

Hi all....

Since the two main sources for the 6 pin connector are both out of
stock (Allied and Mouser), I thought I'd let you people know...

I happen to have access to some 6 pin connectors without the
strain relief.  If you would like one, let me know.  I don't know how
much they will cost yet, but it will be less than full price (i.e. less
than $0.66).  However, since they're so cheap, it's kind of pointless
to get only one (depending on how you pay, postage will increase
the price from 50-100% :) but you can if you want.  I only have a
limited amount, so it's basically first come first served (and please
note that I am not making any money off this).  The earliest I will be
able to get them out is Wed. (the 27th)

Also, I am working on a parts list for the webpage, it will be for
digikey since their website is the best IMO :).  Oddly enough,
Radio Shack has the best price on boxes/containers/housings etc,
and the best price on PC boards (they sell cheaper quality ones,
which is why, but they are good enough)

And finally, I'd like to point out that if you don't have a soldering
iron, and are planning on doing any electronics projects in the
future or would like to do something of the sort, instead of this
being a one-off thing, (gee, that was really badly worded) then you
would be better off buying a temperature controlled soldering iron,
instead of the $8 one from Radio Shack.  It will cost about $200,
but it will last forever. (My friend has been using the same one for
>20 years and it still works fine!)  Just some advice.

Josh

----- Original Message -----

From: Mark Pauker

To: jp1@egroups.com

Sent: Saturday, December 23, 2000 2:28 PM

Subject: [jp1] Re: 15-1994 Remote Checksum

Hi Dan!

Now I'm a bit confused.  (What a surprise!)

When I got your message about the checksum applying to locations 002-7FD (or
002-3FC in 1K units), I went back to the Memory Map document and verified
what you said.  The problem is that that's not what I found in the remote
itself.  I used remoteif to download data from a virgin 15-1994, and found
that the checksum is an xor of locations 002-7FF.  I went back to all the
dumps that Rob sent me and found the same thing.  (I included some of these
dumps in the zip file I sent with the "pre-alpha" version of the Windows
program I'm writing.)

So what stupid thing am I missing now?

On an unrelated note:  I understand that timing is very important in the
remoteif routines, but not having experience writing directly to the ports,
I'm not sure exactly how you achieve the timing sync.  Is it the case that
(regardless of processor speed) it always takes 1.0 - 1.5 us to read the
status register, and thus the at24Cxx_get function takes that amount of
time, regardless of hardware/os?

-- Mark

----- Original Message -----
From: "Dan Nelsen" <dhn@...>
To: <mpauker@...>
Sent: Friday, December 22, 2000 1:44 PM
Subject: Re: Fw: 15-1994 Remote


> > From mpauker@... Fri Dec 22 07:30:14 2000
> >
> > Thanks for making the source code available.  I'm sure I'll have some =
> > questions about timing issues, etc., but I'll post those to the jp1 =
> > group.
>
> Thanks (in advance) for helping out the project.
>
>
> > In my initial scan of your code, I think I found a bug in your do_load =
> > proc.  In the case of a 1K eeprom, you set the chkrange variable to =
> > 1021, but in the case of a 2K eeprom, you set it to 2046.  Depending on
=
> > the boundary conditions of your loop (which I'm a bit too brain-dead at
=
> > the moment to analyze myself), either the 1K value is too low (which I =
> > think is the case), or the 2K value is too high.
>
>
> It's correct, but not as clear as it could be (I should have made it hex).

>
> For the 2k-byte EEPROM, the checksum is the XOR of locations 002-7fd
> For the 1k-byte EEPROM, the checksum is the XOR of locations 002-3fc
>
> chkrange is set to either 0x7fd+1 or 0x3fc+1
>
>
> ________________________________________________________________________
> Daniel H. Nelsen                                email:  dhn@...
> PMC-Sierra MIPS Processor Division
> Santa Clara, CA
> ________________________________________________________________________
>
>



To unsubscribe from this group, send an email to:
jp1-unsubscribe@egroups.com

Hi Dan!

Now I'm a bit confused.  (What a surprise!)

When I got your message about the checksum applying to locations 002-7FD (or
002-3FC in 1K units), I went back to the Memory Map document and verified
what you said.  The problem is that that's not what I found in the remote
itself.  I used remoteif to download data from a virgin 15-1994, and found
that the checksum is an xor of locations 002-7FF.  I went back to all the
dumps that Rob sent me and found the same thing.  (I included some of these
dumps in the zip file I sent with the "pre-alpha" version of the Windows
program I'm writing.)

So what stupid thing am I missing now?

On an unrelated note:  I understand that timing is very important in the
remoteif routines, but not having experience writing directly to the ports,
I'm not sure exactly how you achieve the timing sync.  Is it the case that
(regardless of processor speed) it always takes 1.0 - 1.5 us to read the
status register, and thus the at24Cxx_get function takes that amount of
time, regardless of hardware/os?

-- Mark

----- Original Message -----
From: "Dan Nelsen" <dhn@...>
To: <mpauker@...>
Sent: Friday, December 22, 2000 1:44 PM
Subject: Re: Fw: 15-1994 Remote


> > From mpauker@... Fri Dec 22 07:30:14 2000
> >
> > Thanks for making the source code available.  I'm sure I'll have some =
> > questions about timing issues, etc., but I'll post those to the jp1 =
> > group.
>
> Thanks (in advance) for helping out the project.
>
>
> > In my initial scan of your code, I think I found a bug in your do_load =
> > proc.  In the case of a 1K eeprom, you set the chkrange variable to =
> > 1021, but in the case of a 2K eeprom, you set it to 2046.  Depending on
=
> > the boundary conditions of your loop (which I'm a bit too brain-dead at
=
> > the moment to analyze myself), either the 1K value is too low (which I =
> > think is the case), or the 2K value is too high.
>
>
> It's correct, but not as clear as it could be (I should have made it hex).

>
> For the 2k-byte EEPROM, the checksum is the XOR of locations 002-7fd
> For the 1k-byte EEPROM, the checksum is the XOR of locations 002-3fc
>
> chkrange is set to either 0x7fd+1 or 0x3fc+1
>
>
> ________________________________________________________________________
> Daniel H. Nelsen                                email:  dhn@...
> PMC-Sierra MIPS Processor Division
> Santa Clara, CA
> ________________________________________________________________________
>
>

<<Okay...  Am I correct that no matter what the situation, the EFC would still
track with the hex code?  (In other words, hex code F7 is always EFC 117.)
Further, hex code F7 will correspond to either command code 16 or 239 if LSB, or
command code 8 or 247 if MSB.>>

This is 100% correct, no exceptions whatsoever [that I know of :) ]

<<Have I got it yet Higgins?>>

You are closing in on the promised land my friend!

Hey, I've got an idea for a GUI program that you could probably throw together
really quickly.  Could you develop a GUI program that you can use to open and
edit a dump file, this program should just be a big editable panel with a list
of hex addresses shown to the left of the editable box, and it should remove the
address info that is at the beginning of each line.

The idea being that you can add a byte here and there and maybe remove a byte
here and there and the text will wrap around and line itself up as it should be.

For those of you that have dumped the memory of your 15-1994 remotes, you should
try out the disdump and asmdump programs on my site.  The disdump program breaks
up the info and displays it in a slightly more readable format, which can edit.
Once you have done editing it you can then use the asmdump program to
re-assemble it into the standard dump format.

As I start to create new device codes, i will store them in the format that
asmdump expects and list them on my site, the idea being that you can cut and
paste them into the file for your remote without you having to lose all of your
existing settings.

At this point the programs can only handle the 15-1994's memory, but they will
probably be upgraded in the future to handle many different remotes memory.

Rob.

<<If I understand correctly, the hex for LSB command 16 is $F7, with a
corresponding EFC of 117.  The same EFC and hex would be used for MSB
command 8.  On the other hand, the hex and EFC for MSB command 16
would be $EF and 53, respectively.  Is this right?>>

Yes, this is true for protocols that have been translated in the "normal" way,
there are examples where they are translated in a "compliment" fashion.  For
example, the Sony protocol is LSB, but hex value "f7" would be used for command
239 (ie, the compliment of command 16).  The RCA protocol is MSB and "f7" would
be used for command 247 (not 8).

<<I think my biggest problem is that the terminology used is very inconsistent.
>>

It can be difficult, I agree, but you have to bear in mind that some of the
documents that you are referring to were created while we were still trying to
figure out what this stuff was ourselves.

<<For example, in your document titled "Memory Map," you
refer to the last byte in the advanced code as "Command Code.">>

Well, in some cases this really is the command code, such as is the case with
the ReplayTV signal, in all other cases it is a version of the command code but
possibly complimented and/or reversed (ie, the binary is the wrong way around).
I now refer to this byte as the "command hex" and will do so consistently from
here on out.

<<This was totally and utterly confusing to me.  First of all, UEIC provides
something they call an advanced code which is an individual number.
Your advanced codes are 5 or 6 bytes.>>

Not true, you are referring to the "Advanced Code SECTION" (SECTION being the
operative word),  In other words this is the section of the memory where the
advanced codes get stored, obviously an advanced code by itself doesn't mean
anything, it needs to be associated with an actual button on the remote (the
first byte of the entry), one of the device keys (the second byte of the entry)
and a device code (the 3rd and 4th bytes of the entry).  The final byte of the 5
byte entries is the advanced code descrambled.  UEIC deliberately puts the
advanced codes through a scrambling program to make it difficult for us to
understand what's going on.

<<Next, the item you list as Command Code is what we are now referring to as
hex, which is
completely different from what is refered to as Command Code in your
replay.shtml document.  >>

It's funny that you use Replay as an example here, because the Replay command
codes are stored exactly "as is", except that they are in hex of course, so
command 1 is "01", command 2 is "02", command 10 is "0a", etc.

<<What UEIC refers to as an advanced code is what we're now calling an EFC>>

The terms EFC (Effective Function Code) and Advanced Code are completely
synonamous, they were coined by different people at different times and are both
in circulation.  I typically use EFC for column headings in Excel spreadsheets
as it is much shorter than trying to fit "Advanced Code" in the heading.  The
ccf2efc program also calls the advanced codes EFC.

<< and the EFC isn't part of your advanced code sequence at all.>>

When you program an advanced code (EFC) to a button, the way it is stored in the
EEPROM is what you are calling the "advanced code sequence".

> So, if you now want to work out what the hex is for command 15,
> you would use the same two columns from the spreadsheet, which
> would tell you that the hex for command 15 is x'0F'

Let's use command 16 instead because command 15 is a bit odd in that
the LSB is the same as the MSB's complement.

If I understand correctly, the hex for LSB command 16 is $F7, with a
corresponding EFC of 117.  The same EFC and hex would be used for MSB
command 8.  On the other hand, the hex and EFC for MSB command 16
would be $EF and 53, respectively.  Is this right?

I think my biggest problem is that the terminology used is very
inconsistent.  For example, in your document titled "Memory Map," you
refer to the last byte in the advanced code as "Command Code."  This
was totally and utterly confusing to me.  First of all, UEIC provides
something they call an advanced code which is an individual number.
Your advanced codes are 5 or 6 bytes.  Next, the item you list as
Command Code is what we are now referring to as hex, which is
completely different from what is refered to as Command Code in your
replay.shtml document.  What UEIC refers to as an advanced code is
what we're now calling an EFC, and the EFC isn't part of your
advanced code sequence at all.

I realize that I'm a newcomer here and that this terminology has been
used in this community for quite some time.  Still, it has taken me
MUCH longer to learn this because of terminology inconsistencies, and
I think we'd be doing ourselves a service by agreeing on a consistent
vocabulary.  I think this is especially important for those who are
just now getting involved (which will probably be a fair number of
people now that you old-timers have gotten us to the point where we
can actually DO THINGS with all this information!)

-- Mark

<<What does ccf2efc do?>>

It converts ccf file (ie, Pronto files) into text files and along the way it
tries to decode the IR signal and tell you what the protocol, device code and
command codes are, it also tells you the advanced code needed to recreate this
particular button.

Here's some background.  People with the Philips Pronto touchscreen universal
remote can hook them up to their PC's and save their configurations.  The Pronto
has almost no device codes preloaded, so everything has to be learned.  There is
a file section at Remote Central where people have saved their configurations
for others to share.

When someone asks a question about a certain device, I will usually go to the
Pronto section and see if there's a file for that device, if there is I will
download it and then run ccf2efc against it.  The output file shows all the
signals in Pronto hex format along with the IR information.

I would like to get it to recognize a few more protocols that are not currently
programmed.  I would also like it to display the hex code for the protocol if I
have already found it, and I would like it to display the command hex for the
command.

We could even make a version of the program that expects a ccf file to be in a
certain format with the buttons labelled a certain way, then whenever I have a
remote for a device that doesn't have a device code in the 15-1994, I could
simply learn all the commands into the Pronto and store it in this file, then I
could just run this new version of the program against it and it could create
the code that I would need to add to the EEPROM memory in the 15-1994, this
would save me ALOT of time.

Mark, I'll send you a couple of files that you can play with.

Rob.

----- Original Message -----

From: Robert Crowe

To: jp1@egroups.com

Sent: Friday, December 22, 2000 11:25 AM

Subject: [jp1] Anyone wanna try fixing up a program?

I have just been given the source code to John Fine's "ccf2efc" program, which
is itself based on the older "listccf" program.

There are several changes and enhancements that I'd like done to it, but I'm not
a C programmer, anyone feel like taking a crack at it?  If so, let me know and
I'll send you the source code.

Once you're familiar with it, I'll tell you what changes are needed.

Later,
Rob.




To unsubscribe from this group, send an email to:
jp1-unsubscribe@egroups.com

I have just been given the source code to John Fine's "ccf2efc" program, which
is itself based on the older "listccf" program.

There are several changes and enhancements that I'd like done to it, but I'm not
a C programmer, anyone feel like taking a crack at it?  If so, let me know and
I'll send you the source code.

Once you're familiar with it, I'll tell you what changes are needed.

Later,
Rob.

<<Just a thought, but if there are no formulas in the
spreadsheet, you might want to convert it to a CSV
(comma delimited format) file, so people who don't have
Excel (e.g. me :-) can open it.>>

No formulas?  HA!  The thing is riddled with formulas, quite complicated ones
actually, but I have just created a text version that you should be able to
read.

Rob.
(See attached file: OBC-to-HEX.txt)

-----Original Message-----
From: jtasker@... [mailto:jtasker@...]
Sent: Friday, December 22, 2000 10:58 AM
To: jp1@egroups.com
Subject: Re: [jp1] EFC to hex spreadsheet

> I have just made a new version of the EFC to hex
spreadsheet that should
> simplify things a little (if that's possible with
something as complicated as
> this).

<snip>

> (See attached file: OBC-to-HEX.xls)


Just a thought, but if there are no formulas in the
spreadsheet, you might want to convert it to a CSV
(comma delimited format) file, so people who don't have
Excel (e.g. me :-) can open it.

Josh


To unsubscribe from this group, send an email to:
jp1-unsubscribe@egroups.com

> I have just made a new version of the EFC to hex
spreadsheet that should
> simplify things a little (if that's possible with
something as complicated as
> this).

<snip>

> (See attached file: OBC-to-HEX.xls)


Just a thought, but if there are no formulas in the
spreadsheet, you might want to convert it to a CSV
(comma delimited format) file, so people who don't have
Excel (e.g. me :-) can open it.

Josh

In order to fully convert the command hex into the true command code you would
need to know what kind of protocol you are dealing with, but you can convert it
to an advanced code without this information.  Hex '7f' will always translate to
advanced code 185 regardless of what protocol is in use.  If the protocol is an
LSB protocol, this will translate to command 1 (or command 254 if the compliment
is used), if the protocol is an MSB protocol, this will translate to command 128
(or 127 if the compliment is used).

OK, if that didn't confuse you yet, this will...  In reality, the stuff I just
mentioned about using the normal command code vs. using the compliment is
actually reversed, but all of the tables that we have already established in the
remote community that translate EFC's (advanced codes) to command codes are
based on doing it this way around.  This is because this is how the most common
protocol(the NEC protocol) is set up.  I didn't discover that they are really
using the compliment until I saw the actual hex in the memory dump.

I have just made a new version of the EFC to hex spreadsheet that should
simplify things a little (if that's possible with something as complicated as
this).

Here's how you would use it.  If you know that the hex for a certain command is
x'7F' and you also know that the true command code for this command is 1, then
from the spreadsheet you can determine that you are dealing with an LSB protocol
in normal mode.  So, if you now want to work out what the hex is for command 15,
you would use the same two columns from the spreadsheet, which would tell you
that the hex for command 15 is x'0F'

Rob.

(See attached file: OBC-to-HEX.xls)

This is the first message to jp1@egroups.com
Enjoy.
Rob.