• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

WTB: Remote for Topping DX7

thefsb

Addicted to Fun and Learning
Joined
Nov 2, 2019
Messages
796
Likes
657
The DX7 comes with a very nice remote so you don't need to use a universal one.
The problem is remote proliferation.

1 for the amp - volume up down
1 for the DVD player
1 for the video streamer
1 for the HDMI switch
1 for the DAC input selection
1 for the projector

Doesn't matter how nice the new remote is, it adds to the madness.
 

Jimster480

Major Contributor
Joined
Jan 26, 2018
Messages
2,895
Likes
2,055
Location
Tampa Bay
The problem is remote proliferation.

1 for the amp - volume up down
1 for the DVD player
1 for the video streamer
1 for the HDMI switch
1 for the DAC input selection
1 for the projector

Doesn't matter how nice the new remote is, it adds to the madness.
Buy a programmable remote like the Logitech harmony.
 

fustyler

Member
Joined
Sep 30, 2018
Messages
8
Likes
0
I have a D90, tried the irplus app with the imported file on a xiaomi phone with IR blaster. Unfortuately didn't work.
 

b4nt

Addicted to Fun and Learning
Joined
May 29, 2021
Messages
803
Likes
270
If your HTPC has a receiver and not just a blaster, you might be able to find a program that can access it. Most of the recommendations I'm seeing are to grab an Arduino and use that, but I'm betting that setup is non-trivial also. I'd think that if you had an IR-receiver and an oscilloscope, you could get the raw I/O stream, which is easy to convert using any of a number of websites out there.

FYI, Topping service did provide the attached C files, which I assume are the sections of CPLD code that control the IR inputs. I could not distinguish the protocol from these, but perhaps one of the more experienced members of the forum could. I did make a half-hearted attempt to translate the Chinese characters in the IR.c file header lines.

Hi, according to your attachment, it may be a NEC protocol. Start of frame/timings of bits and frame seem similar.

Codes themself like TP32EX_YKQ_IR_OPT / 0X12 (8 bit command) arent't sufficient.
A frame shoud be stuffed with additionnal data. Here is an example I found on the internet, for NEC:

https://exploreembedded.com/wiki/NEC_IR_Remote_Control_Interface_with_8051
And from there:

When a key is pressed on the remote controller, the message transmitted consists of the following, in order:
  1. A 9ms leading pulse burst (16 times the pulse burst length used for a logical data bit)
  2. A 4.5ms space
  3. The 8-bit address for the receiving device
  4. The 8-bit logical inverse of the address
  5. The 8-bit command
  6. The 8-bit logical inverse of the command
  7. A final 562.5µs pulse burst to signify the end of message transmission.

9ms, 4,5ms, then 4 bytes of data. It might be tested further with the Arduino IR lib, which supports NEC (and many other protocols):

https://github.com/Arduino-IRremote/Arduino-IRremote Supported protocols: Denon / Sharp, JVC, LG, NEC / Onkyo / Apple, Panasonic / Kaseikyo, RC5, RC6, Samsung, Sony, (Pronto), BoseWave, Lego, Whynter, MagiQues

Shall be easy to sniff and confirm, that would only need an Arduino and an IR receiver.


NEC protocol.PNG
 

b4nt

Addicted to Fun and Learning
Joined
May 29, 2021
Messages
803
Likes
270
That seems to be the command check part of code (command code compared to 8-bit logical inverse of the command ):

if(((IR_CODE_REC.IR_CODE_8.IR_DATA_CODE|IR_CODE_REC.IR_CODE_8.IR_DATA_CODE_F)==0XFF)&&
((IR_CODE_REC.IR_CODE_8.IR_DATA_CODE&IR_CODE_REC.IR_CODE_8.IR_DATA_CODE_F)==0X00))
{
IR_Decode_Stage = REPEAT_TEST;
IR_CODE_REC.IR_OK = 1; //½âÂëÕýÈ·
}


And according to the provided IR.h.txt file, first two bytes of frame shall correspond to:
#define RC_20_USER_CODE 0X8877

0x8877 is 1000 1000 0111 0111 binary, so again, destination/reverse of the destination.

Shall be a basic NEC protocol, from timings to frames contents.

Main point to double check are the commands, to send the correct ones to the DAC. Like such (to be confirmed, code contains some variants):

#define RC_1X_IR_HEADPHONE 0X04
#define RC_1X_IR_LINEOUT 0X40
#define RC_1X_IR_INPUT_L 0X47
#define RC_1X_IR_INPUT_R 0X15
#define RC_1X_IR_VOL_INC 0X46
#define RC_1X_IR_VOL_DEC 0X16
#define RC_1X_IR_MUTE 0X06
#define RC_1X_IR_POWER 0X18
#define RC_1X_IR_HEADPHONE_LINEOUT 0X55
#define RC_1X_IR_A 0X10
#define RC_1X_IR_DIS 0X14
#define RC_1X_IR_FIR 0X54
#define RC_1X_IR_IIR 0X50

Edit: codes list should be correct, see source codes at previous posts here, plus:
https://github.com/irplus-remote/irplus-codes.github.io/issues/379


Required, by the NEC protocol, frames repetitions, for confirmation (and to deal with lossed or altered frames), an amount to be checked also, I didn't have a look at that part inside Topping's code:

IR_Decode_Stage = REPEAT_TEST;

I would now build some frames and send 3 to 5 to the DAC to see what happens... Or with any universal command, test some frames using those informations and NEC frames.

PS1: I first had a look inside the remote controller for some hints. But there, we won't learn more, don't destroy yours, it is based on AD009-08, an OPT (One Time Programable) microcontroller (the attachment).

PS2: and that is probably a path to investigate for a very cheap alternate DIY device to control a Topping DAC, like a remote volume/mute button:
https://forum.arduino.cc/t/lightweight-arduino-ir-library-for-nec-remote-control-devices/595247
https://gist.github.com/EEVblog/6206934
 

Attachments

  • ToppingRC.png
    ToppingRC.png
    771.7 KB · Views: 181
Last edited:
Top Bottom