Z-Master what I mean is that the IR signal can indeed be transfered by a wire. On Pioneer and most other receivers you offen have a control input using a mini jack 3,5mm.
That signal is crucial because you dont need to have the receiver in IR range.
However I cannot get it to work with current remote settings in RemoteTwo.
The signal captured with the remote onto RemoteTwo for the volume up is:
For my current setup the (Lintronic)
Is in decimal:
727 165 010 000 000 000 000 001
The actual Pioneer code for volume up is A50A as per Pioneer specification. That translated to the decimal is the 165 010. And the last octet is the repeat number.
The first 727 is the code id.
But can anyone tell me the specs for:
The first seems to be the Hex code but it should have been A50A according to my current setup and specification as A55A actually is some different command than volume up.
And what is 50AF?
So a specification of the remote two IR Hex format will be nice
There are two possible ways of firing a “blaster”: with the anode held at +VCC ground the cathode, or with the cathode grounded pull the anode to +VCC. I don’t know whether there is a standard for which way it is done. Also, for an “eye” to work, it has to have DC on one end. Again, the options are use it to complete the plus connection, or the ground connection. This complicates simply connecting a hub output to a device input and expecting it to work. If you know exactly how each end is wired and know some electronics, you may be able to use a coupling capacitor and/or clamping diode. I’ve never tried this. But the safest way is simply to make your own optical coupler: tie a blaster and eye back to back and plug each into its appropriate jack. This is ugly and kludgy, but you can usually hide it in back of the track or piece of equipment. The optical path is 100% reliable, and it doesn’t matter if the eye saturates because it isn’t operated in a linear fashion anyway.
I don’t think the hex code format has anything to do with it.
bits is the length of the number of bits in the data (some protocols don’t use multiples of 8 bits)
repeat-count - number of signal repeats
According to the code you’ve pasted it’s NEC protocol. The IR data may not be compatible with other IR projects as it’s specific to just the way this project decode and encode the IR data. I’ve glanced through the code for NEC:
1st byte (0xA5) is a device address.
2nd byte (0x5A) is just an inversion of the address (0xA5 xor 0xFF = 0x5A).
3rd byte (0x50) is the device command (volume up?).
4th byte (0xAF) is just an inversion of the command (0x50 xor 0xFF = 0xAF).
The inversions in NEC protocol are there to make sure the receiver in the device received the signal correctly. If the inversions are not correct, the signal is ignored. There’s also an extended NEC protocol (NECx) in which 2nd byte is not inversion of the 1st one, but contains a subdevice address.
There can be at least two possible reasons why the wired input doesn’t work for you. One is the one @Wotan mentioned regarding the polarity of the signal.
The other reason may be that the wired input requires the signal to be non-modulated. The output from Remote Two base’s extender port is modulated for sure. If your device require non-modulated signal in wired connection then it won’t work directly with the output from the base.
What does that mean that the signal is modulated or non-modulated? Modulation means that the encoded digital data is superimposed on the pulse width modulated signal of specific frequency. For example, for NEC the frequency is 38.4 kHz. The IR receiver looks for pulses of light of this frequency first and if it finds it, then it demodulates it to a non-modulated signal.