JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

DecodeIR, RM and KM request: Yamaha extended NEC gap signals
Goto page Previous  1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Sun Nov 28, 2010 10:07 pm    Post subject: Reply with quote

The difficulty is that there are perhaps 5 other threads that have most of the detail and discovery. This thread started out just as a request for software.

Anyway, you would subtract from 127 only for the signals which decode as gap. Or just convert the 3rd hex byte in the Misc column to decimal.

What receiver is it? We have access to a number of Yamaha issued documents which purportedly list the implemented functions. From my point of view, pulling the data from a document is a lot easier than learnign and decoding signals. Maybe we can point you to the "official" list of functions.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Sun Nov 28, 2010 10:27 pm    Post subject: Reply with quote

Liz, in the first post of this thread I have asked for the software to be updated to support this new protocol and while KM and RM have been updated, DecodeIR has not, so that's why you're having problems. If DecodeIR had been updated, it would give you the correct OBCs and tell you which version of the Yamaha signal is being used (there are 3 versions).

I would strongly recommend AGAINST using the 127-obc method to get the OBC because, IIRC, that will only work for 1 of the Yamaha variants.

It's a much better idea to convert the third byte of the hex code into decimal and use that.

Or, you could do what I did and grab the raw timings for all the signals, convert them into binary and go from there! Then again, maybe you should stick with the hex code after all! Smile
_________________
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
View user's profile Send private message Visit poster's website
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Sun Nov 28, 2010 10:30 pm    Post subject: Reply with quote

I just, for the first time, read the threads Rob linked to at the beginning of this thread and clearly see all this goes back to 2009 Sad
This says exactly what you said
http://www.hifi-remote.com/forums/viewtopic.php?t=11604&postdays=0&postorder=asc&&start=15

I can probably muddle through at this point even though I don't understand how those SCENE things are supposed to work (if at all)

Receiver is RX-V567, OEM remote is ... hmmm ... 2 numbers: RAV334 and WT92700. I have the manual as well as the list of device setup codes for, I think, the scene buttons. I don't think I'll need any of that.

I think Rob based his file on jetstar52 file for apparently a very similar box.
Yamaha_HTR-5063-RX-V567.txt
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Sun Nov 28, 2010 10:39 pm    Post subject: Reply with quote

The Robman wrote:
I would strongly recommend AGAINST using the 127-obc method to get the OBC because, IIRC, that will only work for 1 of the Yamaha variants.

It's a much better idea to convert the third byte of the hex code into decimal and use that.

OK, sounds good. Looks like 127.1 group also will need work.

The Robman wrote:
Or, you could do what I did and grab the raw timings for all the signals, convert them into binary and go from there! Then again, maybe you should stick with the hex code after all! Smile

There must be a 100 buttons on the freaking OEM remote. And I've recorded in the widget >120 functions, many just for the buttons that I think are related to those scenes whatever they are. I think I'll do the hex way.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Sun Nov 28, 2010 11:27 pm    Post subject: Reply with quote

Excel converted third hex bytes in a jiffy. Filter clearly shows that all 122.133 and 127.1 need attention if I want to put my stuff into KM.
In this instance 127-badOBC would've worked.

I knew you guys are good. But this is an amazing work on those NEC variants. Thanks a million for handholding.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Nov 29, 2010 3:23 am    Post subject: Reply with quote

Liz,
This is probably too late for you to try, but I have uploaded a test version of DecodeIR.dll (called version 2.41a) which should decode the gap signals, giving the correct OBC and Y style.

I've only tested this with IRTool, using Pronto Hex from Yamaha. And a couple of other IR protocols to see if they still work.....

I'm not smart enough to get this to compile so that it is compatible with Java, so I commented them out, but it seems to work under Windows.
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Mon Nov 29, 2010 4:20 pm    Post subject: Reply with quote

Works like a charm Smile
I checked several buttons of 121, 122, 122.133, 124, 126, 127.1 - all ok
I also checked Panasonic, Denon and JVC. Nothing broken.

Does Y1 here and in KM stand for Yamaha variant of NEC1, so a Y2 would refer to NEC2 or something like that?
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Nov 29, 2010 4:39 pm    Post subject: Reply with quote

Liz,
Glad to hear it works. This version of the dll has probably broken decoding of NECx2 and NEC2 signals, and I'll work on that soon.

There are three Yamaha variants, and they are all NEC1-like signals in the repeat behavior. For Y1, the 3rd and 4th bytes sum to 7F or 17F, while Y2 and Y3 add to slightly different numbers. See the protocol notes in RM.

From a bit perspective, ordinary NEC will make the 4th byte to be the bitwise complement of the 3rd (OBC) byte. Another way of expressing that is byte4= 0xFF- byte3; another way is the bitwise XOR of byte3 and byte4 is 0xFF; still another is byte4=(byte3^0xFF) where ^ means XOR. Since byte4 is completely determined by byte3, the receiver can use this as a check for an error in transmission.

Y1 has byte4=byte3^0x7F
Y2 has byte4= byte3^0xFE
Y3 has byte4=byte3^0x7E

This way, Yamaha quadruples the available function numbers while still getting 6 bits for error detection.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Mon Nov 29, 2010 5:14 pm    Post subject: Reply with quote

Dave, I have no proprietary interest in maintaining DecodeIR.dll. After all, it isn't my program, it belongs to John Fine. There is no trick about compiling Java compatibility, all you need is the JDK and to make sure that the right locations are set for the include libraries. So feel free to make an official v2.42 if you wish - you would not be treading on my toes.

I assume you started from the latest source for v2.41, the one that includes Mac OS X compatibility too. If not, then you should do so if you want to make it official.
_________________
Graham
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Nov 29, 2010 6:06 pm    Post subject: Reply with quote

I'm not sure if I'm competent to make an official version--I don't understand anything about the decoding of the signals, and very little about the program flow.

My specific problem with Java is aggravating-- Visual Studio Express 2008 says it can't find jni.h, even though I think I have the directory path (to the JDK) set correctly. I've also put a copy of jni.h in the same directory as the the rest of the project files, but without success. I'll figure it out.

I believe that I have the latest source.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Mon Nov 29, 2010 6:58 pm    Post subject: Reply with quote

Dave,
I've done some testing and while your logic does appear to differentiate between NEC and NECx, it doesn't differentiate between NEC1 and NEC2

Would it be possible to reformat the protocol name so it displays as NEC1-y1, where the part before the dash is the true NEC format (ie, NEC1, NEC2, NECx1 or NECx2) and the part after the dash is the Yamaha version?

I have created an IR file that you can use for testing:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9192

The first 4 learns (in CBL mode) come from the ICT file that was posted earlier. These don't repeat, so you can't tell if they're NEC1 or NEC2, so these should just display as NEC-y1.

The rest of the learns were generated by hand (by me).

The next 4 learns (in TV mode) show what NEC1-y1, NEC2-y1, NECx1-y1 and NECx2-y1 would look like.

The next 4 learns (in VCR mode) are normal NEC1, NEC2, NECx1 and NECx2 signals, just to make sure that you don't break anything. However, I should point out that I notice that NECx1 is being incorrectly displayed as NECx2, and this appears to pre-date your version).

The last 3 learns are NEC1-y1, NEC1-y2 and NEC1-y3.
_________________
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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Mon Nov 29, 2010 9:17 pm    Post subject: Reply with quote

Rob,
Yes, as I told Liz, I anticipated that NEC2 and NECx2 wouldn't work correctly.

I agree with with describing the signals as NEC1-y1. However, I have to change more of the program to do that. As I understand it, DecodeIR first determines that the signal is generic NEC, then decides if it is NECx or NECx1, and then does a separate step to check for NEC2 or NECx2. The program carries the knowledge that the signal is generic NEC in the protocol name, and appends 1, x1, 2, or x2 to the string when and if it fully recognizes the signal.

The new logic has to recognize that the signal is the Yamaha style of generic NEC, and it needs to do that at the beginning. So my first attempt gave results like "NEC-y1x1". As a temporary measure, I put the Y information at the beginning of the string, so that the x1 or 1 suffixes would be correct, but that breaks NEC2. (Or perhaps it breaks the difference between NEC1 and NEC2. I don't have access to the code at the moment.)

This can be handled in a couple of ways, and I'll get something better out soon.

Thanks very much for the IR testing file. That's going to make things much easier!
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Mon Nov 29, 2010 9:42 pm    Post subject: Reply with quote

I'm guessing that the generic NEC logic requires that the last byte be the complement of the OBC byte. Maybe the way to do it is to remove that early test, then once all the other NEC details have been ironed out, you can test that byte. If it's the complement of the OBC, you've got a normal NEC variant. If it matches the known Yamaha variants, you can add the suffix. If it's anything else, you could add "-like" (eg, NEC1-like) and then put the decimal value in the "misc" column.
_________________
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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Tue Nov 30, 2010 12:06 pm    Post subject: Reply with quote

Putting the check for byte4 == (~byte3) last would mean a complete re-write of DecodeIR. So I've handled it via string manipulation.

Now the dll does show NEC1-Y1, and the other Yamaha styles. I haven't fixed the apparent issue that NECx1 is decoded as NECx2, nor have I implemented the display of the general case of byte4 <> byte3. I'll work on those soon.

Decoding the learned signals you posted seem to have some issues. The standard NEC signals work, except for NECx1. As you expected the first 4 learns from an ICT file decode aren't decoded to NEC1 or NEC2. However, some of the other signals also don't resolve to 1 or 2, both in the second set and the last set.

I can see in the last set that the Y1 signal (which does decode to NEC1-Y1) has 50 bytes of learned data, while the unresolved Y2 and Y3 signals have 40 bytes. IRv8.03 outputs an attempt to put learned signals into IRP notation, and that routine also finds variances in the form of the signals.

I have one spreadsheet from Yamaha that give Y1 signals in Pronto Hex format, and these are properly decoded. I plan to hand modify the Pronto Hex to make the other styles to see if those are properly decoded.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Wed Dec 01, 2010 4:31 am    Post subject: Reply with quote

Newer version (2.42b) posted. Decodes ordinary NEC styles, Yamaha styles, and also shows any other byte3/byte4 combinations as style "-f16", which is intended to mean a 16 bit function number. -f16 shows the 4 bytes in the Misc section. It may be desireable to reverse the order of the bits?

Lightly tested in RMIR, IR, and IRTool.

Rob, using a RCRP05B to send the built-in Audio 1293 (NECx1) and 1295 (NECx2), I don't see any problem in decoding these signals. I'm not sure why the file yamaha-gap.ir shows a problem with the NECx1 signal.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5  Next
Page 4 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control