JP1.X upgrades via MP3 files?? Why not??

[Mark Pierson]

I was asking if the current serial transfer method of downloading an image, a file, whatever is sent to my JP capable remote could be done using MP3 or WAV.

Short answer: yes. Wav files are already an option for the remotes that support them. Long answer: see above.

I don't know what you guys call the entire image or file that is sent via the JP cable.

It's a complete image of the EEPROM, typically 2k bytes. It contains all the "setup" information for the remote such as:

setup codes assigned to the various device buttons
status indicators for things like volume and channel lock
macros and key moves
device and protocol upgrades (to supplement or replace the built-in code library)
learned signals

It's all the data from the Raw Data tab in IR.

Just wondering if it can be done and hoping someone would provide some positive, healthy, exchange of information.

I thought the previous exchanges had been healthy, and sometimes even negative feedback is positive.

Truth be told, I'm not a hardware expert by any stretch. Any negativity I may have displayed comes from the trials and tribulations we've already gone through with the current interfaces and their idiosyncracies. I just don't see how a non-mainstream approach to that could be any simpler (that's not to say it can't be done; anything's possible with enough time, money, or both ).

[The Robman]

Files generated in Keymaster, Remotemaster are saved and/or subsequently transmitted serially, whether by a RS232, Parallel or USB cable to a 6 pin connector.

Not exactly, there's a step in-between that's missing. KM and RM files are designed to be opened and manipulated using KM or RM, this is where you have the chance to select the remote that you are trying to program, for example. The resulting data is then copied over to the IR program and it is this program that communicates with the remote.

So, even if someone were to invent an MP3 interface, the MP3 files would replace IR files, they would not replace KM and RM files, so the user would still need to use the RM or KM programs to manipulate the upgrades.

Furthermore, as has been pointed out, the MP3 method would suffer from the same shortcomings that the current WAV method does, and that's the fact that it's a 1-way communication, so the user would have no way to extract data from the remote using the MP3 interface.

[Ex-Navy]

So as I understand it correctly, KM and RM are used for manipulating remote data (button info, protocol codes, device code, etc etc)

Ir.exe is used to read from or download that data to the remote.

Out of the 6 pins on the remote's 6 pin header, are all 6 used?

What are the function names?

Are ones used common to all Jp1, Jp1.2 and Jp1.3 type remotes??

I have a JP1, a JP2 and a JP1.3 remote.

What is the difference in the versions??

[unclemiltie]

First, the JP1 and JP1.x interfaces are very different.

The JP1 interface is a "direct connect" to a I2C bus on the EEPROM in the remote. One of the pins is pulled down to tri-state the processor bus (it resets the processor) and there are then three pins that need to communicate with the I2C (SCL, SDA and of course ground) I don't know if the other two pins are used, but that should give you an idea of what they do. The drivers for the cables used by IR directly manipulate these bits on the connector. (ie: the parallel cable just twiddles these bits)

The JP1.x interface is a true serial IO interface (ie: it responds to EIA 232 standards) at a serial bit rate, etc. There are then commands that can be sent to the remote, which will then tell the controller inside to do something which then may expect data to come at it or can start shooting data out. These have a RX, TX and ground as well as a pin that tells the remote to start to listen.

As for your original idea. Sure you could:

1: develop a way to turn the contents of an IR file into a sound file
2: build a piece of hardware with the above interfaces that knows what the sound file looks like and how to convert it back into bits that can be shoved down the cable and then shoves them down the cable doing just what IR does.

That cable would be much more expensive than the existing cables today and the previously mentioned downside of not being able to read back from the remote would probably limit you to only those who REALLY don't want to try it with a PC.

So, the bottom line (from my standpoint) is

can it be done? Sure, almost anything can be done
should it be done? nope,not worth the trouble.

[gfb107]

A bit oversimplified but:

RM and KM are used for creating and manipulating device upgrades. These contains all the information needed for controlling any single device (TV, DVD, etc). This includes the protocol, protocol parameters, function definitions, and assignment of those functions to buttons.

IR is used for assembling a complete remote image, including multiple device upgrades, assigning those device upgrades (and any builtin setup codes) to device buttons. It also handles macros and cross-device keymoves. There are other unique functions as well, such as extender installation, custom protocols for long/double key press (LKP/DKP), device specific macros (DSM), learned signal decoding, and actual upload/download to the remote.

There are a lot of differences between the various JP1, JP1.1, and JP1.2/3 remotes. There are different processors, different uses for the six pins, and different protocols for data transfer. The JP1 remotes use an I2C type interface, while the JP1.x remotes use a serial type interface.

[Mark Pierson]

Out of the 6 pins on the remote's 6 pin header, are all 6 used?

What are the function names?

Are ones used common to all Jp1, Jp1.2 and Jp1.3 type remotes??

Take a look at Tommy Tyler's interface instructions. He always includes a section describing the operation of the interface that should answer all your questions.

[Ex-Navy]

JP1.x is just one of many forms to upgrade the FLASH in a remote or
any circuit that contains a microprocessor.

I specialize in programming Microchips, 16F, 18F series of microprocessors.

I have purchased one of Tommy's USB cables. It works like a charm and is an excellent, skillfully designed product.

As with any embedded Microprocessor, it's up to the designer to include or not include programming access to the in circuit PIC/AVR

The current JP1.x 6 pin header in the remote can be hacked to add other types of upgrade "interfaces".

I was part of a project where we designed an 16F873 to be upgraded by an infrared interface. The circuit had a TSOP demodulator which decoded Ir upgrade info.

Since alot of remotes have Microchip or their variants in remotes, I thought you might find this interesting.

Here is an excerpt from Microchip's manuals:


Microchip's PIC16F87X family features self
programming capability. Self programming enables
remote upgrades to the FLASH program memory and
the end equipment through a variety of medium ranging
from Internet, Audio, Modem, RF and Infrared. To setup
for self programming, the designer programs a simple
boot loader algorithm in a code protected area of the
FLASH program memory. Through the selected
medium, a secure command allows entry into the
PIC16F87X MCU through the USART, I2C orSPI serial
communication ports. The boot loader is then enabled
to reprogram the PIC16F87X FLASH program memory
with data received over the desired medium. And, of
course, self programming is accomplished without the
need for external components and without limitations
on the PIC16F87X’s operating speed or voltage.

[classicsat]

JP1.x is just one of many forms to upgrade the FLASH in a remote or
any circuit that contains a microprocessor.

Not really. It is the "after manufacture" upgrade interface that UEIC implemented on the next gen upgradeable remotes.

I could be an extension of the chip programming interface though, either locked to reprogram just a portion of the memory, or the whole code Flash, with the right commands. I am not entirely sure.

I specialize in programming Microchips, 16F, 18F series of microprocessors.

I use the Atmel micros. The devices I build have separate interfaces for programming the chip (the ISP interface), and an RS232 serial port I sometimes use to read/write the EEPROM section of memory (sometimes a separate EEPROM chip), in a Monitor mode. Keep in mind, I build the devices for myself to use, not for others

I was part of a project where we designed an 16F873 to be upgraded by an infrared interface. The circuit had a TSOP demodulator which decoded Ir upgrade info.

Did it hard upgrade the system code, or just some variable/settings section? Is there a low level monitor, or the upgrading routine part of the main chip software?

Since alot of remotes have Microchip or their variants in remotes, I thought you might find this interesting.

Not the UEIC remotes, they used Samsung and Motorola, at least.

Franlky, I rarely see PICs, specifically, in CE devices.