Go Down

Topic: Stolen Intellectual Property (Read 6016 times) previous topic - next topic

6v6gt

#15
Dec 08, 2019, 08:45 pm Last Edit: Dec 17, 2019, 02:32 pm by 6v6gt Reason: title change
Incidentally, many people don't realize the IR receiver in a TV or DVR or whatever is only interested in the demodulated signal.  It couldn't care less what the actual carrier frequency is and has no provision for measuring it.  That's just the horse it rode in on.  Of course the narrow bandpass filter in the receiver chip DOES care, and it will attenuate the signal if the carrier is offset from its center frequency.  So carrier frequency error does affect the usable range of a remote control.  One of these days I'll do some experiments to see how far from the TV an 80KHz Sony remote signal will work.  If you check the data sheet for one of those receiver/de-modulator chips you'll find it attenuates the signal about 50% if the carrier is off-center about 10%.      
That, as I understand it, would be illustrated by fig. 5 in the following diagram:
https://www.vishay.com/docs/82459/tsop48.pdf

6v6gt

I've spend a few more minutes looking over the results and have been looking for patterns. I'd start with some assumptions then devise test data (that is generate IR signals for the device to record) to test or break those assumptions. Based on the "60 pulse data" tests, I've got this as a rough first iteration (see attachment)

Riva

Sorry to say for me the data is not concise enough to try and make sense of the ROM dump. Along with the ROM dumps you also need the IR data (like in the "Chunghop copy of sixty pulse signal_4 .JPG" image) that the dump refers to.

I wonder if any value with bit 7 set is taken as a command so 0xAA, 0xAF, 0xC1 are block start/end markers.
Don't PM me for help as I will ignore it.

6v6gt

#18
Dec 09, 2019, 09:50 am Last Edit: Dec 17, 2019, 02:33 pm by 6v6gt Reason: title change
I believe also that the experimental data presented is too comprehensive and much simpler test cases should be run initially (if not already done, that is) to attempt to understand how the data is encoded in the eeprom. Having established how the carrier frequency is encoded, by systematically varying this one parameter as he has done,  the OP could have gone on to understand how the first mark is encoded. For protocols like NEC, incidentally, this is around 9mS.
For this, the tests would probably look like this:

1. Send only a single mark but vary the length and see which byte is changed and how.
2. As above but see what happens when the burst is so long that the byte would overflow to see if it invokes a mechanism to concatenate long bursts.
3. As 1. above, but with a different carrier frequency to see if the burst length is represented in terms of the carrier frequency or in terms of some internal clock controlled by the MCU. Obviously, if the byte does not change when the carrier frequency is changed, then an internal clock is used.

Then continue by sending a space and a second mark, but maybe with lengths different to the first one to prevent any special handling of repeating values that device may invoke.


I can't imagine that the device does more than identifying a carrier frequency and identifying a series of time periods for which the carrier is switched on and off. For example, I would have difficulty believing that if suddenly a manufacturer introduced an IR protocol based on frequency shift keying using 2 carriers, that this device would simply handle all that.

I think this is all a very interesting exercise in reverse engineering and I hope the OP doesn't give up. He has certainly created a well structured test methodology and lab. Naturally, to build a near replica of the ChungHop, it is not necessary to understand all the details of the existing encoding scheme. Just invent a new one with more or less the same capabilities.


OLDokasional

Does comparing these two tests side-by-side reveal anything?


6v6gt

#21
Dec 13, 2019, 11:35 pm Last Edit: Dec 19, 2019, 08:05 pm by 6v6gt
Do you have anything to contradict this for the first 4 bytes:

0x1000: block marker (We've seen only 0xAA so far)
0x1001: carrier speed. Number of clock ticks (4Mhz) for one IR carrier tick. (We've seen only 0x63 so far)
0x1002: Header mark.   units of 40uS   e.g. 0x3C ~= 2400us
0x1003: Header space. units of 40uS   e.g.  0x0F ~= 600 uS

The first 2 have already been determined elsewhere.
No hex dump has been published here which has a carrier other than 40kHz.
If you can generate a few dumps like those outlined in post #18 we may get further.


Edit 1.

I believe that I may also be close to cracking the encoding scheme which makes the encoded data so compact. The findings are consistent with the data you've published so far  for the Sony12 and at the 30/60 repeating groups. Since the data is so sparse (only very few bits set in the unique parts of the data), yet appears to hold so much information, there are only few encoding schemes which are possible. For example, this one allows 60 repetitions of the same pulse to be stored as 15 null bytes.  (see attachment)


Edit 2.

The data blocks are protected with a with a modulo 256 check sum.

Code: [Select]

00000100: AA 63 0F 15 0F 00 15 00 - 04 AF 00 00 40 80 3F 3F 
00000110: 3F 08 C1 20 C1 40 80 04 - 4C A0 1F 60 20 C2 FF FF 
00000120: FF FF FF 00 00 00 00 00 - 00 00 00 00 00 00 00 00 
00000130: 00 00 00 00 00 00 00 00 - 00 00 00 00 3B FF FF FF 


The last (non 0xFF) byte in this example is 0x3B and this is the check sum.
Add up all the previous bytes in the data block (not including the 0x3B), take the HEX value of the sum and throw away everything except the last byte and you are left with also 0x3B.
This could be useful if any of the tests involve editing the eeprom data for subsequent use by the Chunghop.






Go Up