View previous topic :: View next topic |
Author |
Message |
Zibri
Joined: 05 Jul 2012 Posts: 86
|
Posted: Fri Jul 06, 2012 7:39 pm Post subject: |
|
|
Yep the OFA 6 has 2 cells and 3.3v should be fine.
About driving the reset line it should not be difficult but I don't know if it's really needed.
Anyway I was just thinking out loud. The parallel interface seems nice but parallel ports are every day more rare to find in motherboards.
The first interface will take long to arrive from hk but as soon as I get it I will do some quick and dirty tests using linux and the i2c suite. I'll keep you posted about the results but usually it take 20 to 40 days for items to arrive. |
|
Back to top |
|
|
cauer29
Joined: 03 Feb 2010 Posts: 236
|
Posted: Fri Jul 06, 2012 9:12 pm Post subject: |
|
|
Zibri wrote: | Yep the OFA 6 has 2 cells and 3.3v should be fine.
About driving the reset line it should not be difficult but I don't know if it's really needed.
Anyway I was just thinking out loud. The parallel interface seems nice but parallel ports are every day more rare to find in motherboards.
The first interface will take long to arrive from hk but as soon as I get it I will do some quick and dirty tests using linux and the i2c suite. I'll keep you posted about the results but usually it take 20 to 40 days for items to arrive. |
They didn't put the reset line on every JP1 eeprom cable design for no reason. It is required.
A.A. |
|
Back to top |
|
|
Zibri
Joined: 05 Jul 2012 Posts: 86
|
Posted: Sat Jul 07, 2012 5:50 am Post subject: |
|
|
I wonder why. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21271 Location: Chicago, IL |
Posted: Sat Jul 07, 2012 10:32 am Post subject: |
|
|
Take a look at this old doc which explains how to add a JP1 connector to a remote that doesn't have an exposed reset line:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=11068
Quote: | All existing interfaces use the RESET line for disabling the processor so it will let go of the EEPROM's signal lines (SCL and SDA) and let the PC use them for uploading and downloading. |
_________________ 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 |
|
|
cauer29
Joined: 03 Feb 2010 Posts: 236
|
Posted: Sat Jul 07, 2012 11:33 am Post subject: |
|
|
cauer29 wrote: | I'm not much of a software guy, but from what I know of the FTDI combo chip, yes a new or modified existing DLL would be in order. |
A little research reveals that it is true that in order to use the FTDI FT2232 chip with I2C interface requires the use of the D2XX native drivers. There is mention of being able to access both conventional UART comm port and MPSSE mode for I2C via the D2XX native drivers. It isn't clear whether that means that it will still appear as a standard OS comm port, or whether you must do all virtual comm port access through the D2XX interface. If the latter, then it will be some additional work to support JP1.3 operation, in addition to the work needed for JP1 I2C eeprom. See the D2XX programmers guide:
http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf
Here's an example I2C project:
http://www.ftdichip.com/Support/SoftwareExamples/MPSSE/FT2232C-Proj02_v11.pdf
and here's the Delphi source code for the example app:
http://www.ftdichip.com/Support/SoftwareExamples/MPSSE/FT2232C-Proj02_I2C_v11.zip
I have some dim memory from hacking IR to support non-standard comm port addresses, that IR is written in Delphi? If so, it might be not so hard to support JP1 I2C eeprom access via FT2232.
Still need to come up with a solution for the reset line though. In MPSEE mode, the FT2232 appears to have up to 8 GPIO lines available.
And of course, there is the matter of interface voltage. Some folks may be content to simply design for the particular voltage on their own remote, but for a more general purpose cable design, something needs to be done about 2 cell vs 4 cell remotes. The FT2232 chips do have a VCCIO pin that can be used to set the voltage for the interface pins, but it isn't clear if it is legal to use the battery voltage from the JP1 remote to supply VCCIO or not. Certainly at best, we'd need to drop a volt or so off the 6V from a 4 cell remote, to get under the 5.25V max on the FT2232. As long as the FT2232 is happy with VCCIO unconnected until the cable is attached to the JP1 remote, then it may be workable.
A.A. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Sat Jul 07, 2012 12:20 pm Post subject: |
|
|
cauer29 wrote: | I have some dim memory from hacking IR to support non-standard comm port addresses, that IR is written in Delphi? |
Yes. IR.exe is written in Delphi but at present it is not being maintained. I was the last maintenance programmer for it, being responsible for versions 8.00 through 8.03, but I have changed my allegiance and am now doing development work instead on RM/RMIR. If you are a Delphi programmer and would like to modify/extend/maintain IR.exe, you are welcome to do so. You can find the full Delphi source of v8.03 here. However, I believe that future development efforts should be concentrated on RM/RMIR which is written in Java. The latest RM/RMIR development version contains substantial support for JP1.4 and JP2.x, which IR.exe cannot at present handle, and in my opinion the structure of IR.exe would make it difficult to add such support. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sat Jul 07, 2012 2:54 pm Post subject: |
|
|
I strongly support the idea of concentrating further development on RM/RMIR instead of IR. RM is a Java program, with the system/hardware dependent stuff in small loadable objects (Java Native Interface, JNI), namely jp12serial.dll/libjp12serial.so and jp1parllael.dll/libjp1parallel.so.
However, there is one idea I would like to throw in: Would it be possible rewrite RM to use the rxtx library instead of the above mentioned, from our community written libraries? rxtx is more of a standard component, and runs on all relevant systems, and probably better tested. I have not looked too deeply into it; possibly I have overlooked something...
Quote: | RXTX is a Java library, using a native implementation (via JNI), providing serial and parallel communication for the Java Development Toolkit (JDK). All deliverables are under the GNU LGPL license. It is based on the specification for Sun's Java Communications API, though while many of the class descriptions are the same the package used it not, since gnu.io is used instead. A certain amount of compatibility is intended with API, though this project should be considered as a fork and therefore compatible in spirit, but not in implementation. |
|
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21271 Location: Chicago, IL |
Posted: Sat Jul 07, 2012 8:15 pm Post subject: |
|
|
Just FYI, there are some of us that need to keep using IR.exe because it still does things that RMIR doesn't do, as far as decoding learned signals is concerned. Plus, speaking as an expert, most times I need to research something for other people, I need to look at the raw data without bits and pieces being hidden from my view. _________________ 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 |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Sun Jul 08, 2012 7:43 am Post subject: |
|
|
As known, I side with the_Robman on this one.
On the plus side, RMIR eliminates the need to select the remote when opening an upgrade. We all know that was the #1 user error in IR. I find the protocol examiner to have some great features, and have asked Mike for some of those features to be in PB in the future, but in the meantime I use RMIR alongside PB just to simplify things. Heck just last night I was looking at converting my IR files to RMIR files simply for a quick and easy way to dig out information for documentation purposes when I make changes.
I find that the way RMIR obscures information tests the limit of my attention span and wins every time. The cross talk between various RMIR sessions drives me insane. The lack of user control where RMIR makes decisions that may be right for the "masses" but limits experimentation by the adventurous reminds me too much of some of Microsoft's decisions. But in the end, its the "silent" errors that have kept me from adopting RMIR for my own use.
I hate to think of IR being left at the wayside as we explore the new remotes. IR is just too important. |
|
Back to top |
|
|
classicsat
Joined: 20 Feb 2004 Posts: 279
|
Posted: Sun Jul 08, 2012 11:37 am Post subject: |
|
|
Zibri wrote: | I wonder why. |
For EEPROM remotes, it holds the CPU in reset, which lets the interface have control over the EEPROM.
For Flash remotes, it just puts the remote in a "program" mode. |
|
Back to top |
|
|
Zibri
Joined: 05 Jul 2012 Posts: 86
|
Posted: Sun Jul 08, 2012 11:49 am Post subject: |
|
|
Just to make some tests, I just did this:
I tested the 6 pins with a tester and I found voltages of about 2.86v (and since batteries are a little down it makes sense).
After that I used a CA42 (USB<>TTL) cable and connected it to the 6 pin header in this way:
Cable RX to pin 6
Cable TX to pin 4
Cable GND to pin 3
Then I noticed that pressing a button on the remote gave me output!
I don't yet know the right speed and parameters.
Here are some preliminary logs using 19200,38400, 57600 and 115200 speed and 8N1:
https://dl.dropbox.com/u/1587166/URC7650_Logs.rar
Note: I always pressed the same key "1" only once.
I remember I had a utility to detect speed and parameters of a serial line (from the stream itself) but I can't find it.
Any clues about what I am getting?
Note: I didn't connect pin2 for the reset feature because I am just inspecting what I am getting in this situation.
By the naked eye, the right speed seems about 19200 or 38400 8n1 or 8n2.
Edit:
Using realterm I noticed the right speed seems to be 19200 8N1.
Everything else gives framing or parity errors.
Edit2:
Analyzing the data furthermore, they seem to be waveform data.
Probably it's raw IR data.
At 38.400 it makes some sense but I suspect the real speed is the actual IR speed of 38.1khz. |
|
Back to top |
|
|
mdavej Expert
Joined: 08 Oct 2003 Posts: 4519
|
Posted: Sun Jul 08, 2012 12:56 pm Post subject: |
|
|
Before you reinvent the wheel, so to speak, have you had a look at Kevin Timmerman's JP1 EEPROM adapter design? It essentially uses a serial interface and some electronics to bit bang like the parallel interface does. You're way over my head here, but it may give you some insight. |
|
Back to top |
|
|
Zibri
Joined: 05 Jul 2012 Posts: 86
|
Posted: Sun Jul 08, 2012 1:11 pm Post subject: |
|
|
Hmm yes.. but I was trying to accomplis something more similar to " JP1.2 Serial Interface " by tommy.. just for fun And since voltages are about 3v I thought the CA-42 would do just fine.
I just don't understand what I am getting
I think it's debugging data including RAW IR data. |
|
Back to top |
|
|
cauer29
Joined: 03 Feb 2010 Posts: 236
|
Posted: Sun Jul 08, 2012 1:34 pm Post subject: |
|
|
Zibri wrote: | Hmm yes.. but I was trying to accomplis something more similar to " JP1.2 Serial Interface " by tommy.. just for fun And since voltages are about 3v I thought the CA-42 would do just fine.
I just don't understand what I am getting
I think it's debugging data including RAW IR data. |
Why would you want to do something like a JP1.2 interface when your 7560 is a JP1 remote? The two different types cannot be simply interchanged. JP1 uses a direct I2C connection to eeprom, as we have discussed here. JP1.2/JP1.3 uses a very simple TTL serial UART interface that communicates at 38400 baud.
Here's a link to a chart showing all of the different UEI remotes and what interface they use:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=5515
What you are seeing when connecting the CA42 to the JP1 pins, is simply the remote's CPU searching the eeprom for stored info about the key that you pressed. It is not very interesting, as you can't even tell what data is being retrieved from the eeprom without correlating the SDA and SCL lines.
Perhaps it would help you to know that I2C eeprom communication is already built-in to the very PC that you are reading this message on. The EDID monitor plug and play info is read by your computer to determine what resolution, timing, etc that your monitor supports. If I remember correctly you're using Linux and there are tools available to allow direct access to I2C read/write of a monitor's eeprom. All you have to do is rewire a VGA or DVI connector to send the SDA and SCL lines to the appropriate pins on your remote.
A.A. |
|
Back to top |
|
|
Zibri
Joined: 05 Jul 2012 Posts: 86
|
Posted: Sun Jul 08, 2012 4:09 pm Post subject: |
|
|
Hmm no. I'm using mailnly windows but I wrote a program talking onto the i2c bus using the VGA port. I could interface those lines to the remote i2c bus but it's pretty useless I think. I will just build the simple interface then.
My bad.. I thought pin4 was a different pin than SDA line.. I just re-read the schematics and you're right.
My interface just sniffs the i2c bus. Nothing more. It's pretty useless. |
|
Back to top |
|
|
|