Page 20 of 23

Re: Microsoft MCE Remote - Vista and newer

Posted: Sun Jan 05, 2020 4:36 am
by kgschlosser
not a clue.. the kodi elecs are quite unstable. they are a custom operating system that has been stripped in order to run on the lack of resourced those types of hardware typically have.. it should run because the USB stack on them is pretty much untouched as it is the single most used connection point for connecting anything to it....

best bet is to ask the developer of virtualhere. he does answer e-mails/support questions.. virtualhere is free so long as you only have one or 2 devices and it's one a single USB over IP connection being made.. so you can test it to make sure it works without issue..

I was able to write the firmware of an arduino from my PC over WiFi I used a Pi B+ to plug the arduino USB into.. It worked without a hitch.. flashing a micro controller like an arduino is a sensitive task. things can get mucked up easily. it was able to maintain the sped of transmission and do it without any data corruption...

My setup I have several HTPC's in my house. they are all centrally located in my media room. if I want to administer the machine locally I plug in a keyboard and a mouse into a Pi i have attached to the back of the TV. it connects the keyboard and mouse to the HTPC. I also use it for connecting other devices like memory cards.. or a DVD player.. One other feature I use it for is RetroArch. RetroArch is a game system emulator.. It covers most consoles made so long as you are able to provide a console bios to load. well I have some retro game controllers.. NES, SNES, PS1, Sega....., these controllers are USB.. since I can save a game and then run it on another TV in a different room I am able to move the controller as well. If you are going to spend the time to do it then do it right the first time!!!! I ended up using arduinos for the blasting and receiving of the IR because frankly i never even knew it could be done. once I started digging into the code for the current plugin I realized that it was only going to use a single device.. and that more devices could be connected.. up to the limit of however many devices USB is able to handle (which I am is a number so large that you would never plug in that many IR receivers)...


I also learned that there are 2 receiving modes on these IR receivers Wide Band and a narrow band. the narrow band is specifically designed to give the most accurate readings in the 36-38kHZ range. and the farther away from that range the frequency is the less accurate it becomes It has an AGC (automatic gain control) on the receiver that gets adjusted by the first pulse and the first space.. so it will dial the receiver into that frequency for that code.. The second receiving mode Wide band is a learn mode. there is no agc. it is not tuned to a small frequency range.. it opens the gate so anything from 30kHz to 60kHz is going to be received... it is a short range thing tho.. best if used 3-4 inches in order to get an accurate reading.This is how the original plugin was written. It always used this mode to receive all IR. Not good.. no wonder why people would have bad codes they were using their remote from 10-12 feet away and the receiver is picking up any stray IR as well... Most of the commonly used protocols are 36-40kHz which is right there with the sweet spot for using the narrow band receiving mode. I am going to give the user the ability to pick which one they want to use. if their remote is at say 55kHz they may opt to use the wide band mode and they may have better luck with receiving codes accurately. With the decoding I am building in that will take the received code and normalize it to match the protocol specification this should eliminate the false codes all together. I am going to allow the user to turn on and off the "Universal" decoder. The universal decoder is a garbage collector for bad codes basically. If enough of the protocols are supported then there really is no need to have the universal decoder. but there are remotes where the protocol is not known and I do want the user to still be ale to use it. so it can be turned on and off..


I am adding as many protocals that I can. It is hard to get the specifications for them. the manufacturers are very secretive about them for some reason. Some manufacturers will alter an existing specification to suit their needs. so there can be 2 protocols that look identical. but have one slight change made to them. MCE and RC6 is a good example. so is RC6-6-20 and RC6. almost the same but not quite.. RC6-6-20 is used mostly by Sky and Sky+


an IR code is only a bunch of time measurements the length of time the IR is transmitting for and the length of time it is not...


so when you see an IR code in raw format it is going to appear like so (if it is an RTL coded raw code )

Code: Select all

8950 -4400 600 -500 650 -500 600 -500 600 -500 650 -500 600 -500 600 -500 600 -1700 550 -1650 600 -1650 600 -1600 550 -1700 550 -1700 550 -1650  550 -1650 600 -500 600 -500 650 -500 600 -1600 650 -1650 550 -1650 600 -500 600 -500 600 -1650 600 -1650 600 -1650 550 -500 600 -550 550 -550 600 -1650 600 -1600 600 -500 650 10452
I can tell you this is an NEC code just by looking at the numbers..

NEC protocol timing specifications

mark = led is on
space = led is off.. (negative numbers)

IR codes are broken into burst pairs.. a mark and a space. that is a single burst pair.
the numbers above are the length of time they are on or off.
the last 2 values can just be scrapped as they are a lead out and not used to determine the protocol or even used in the protocol

header mark = 9000
header space = -4500
logical 1 mark = 560
logical 1 space = -1690
logical 0 mark = 560
logical 0 space = -560

you have to think of 1's and 0's binary. it's on's and off's the duration of time for the on and for the off is how
we are able to determine if the burst pair is supposed to be a 1 or a 0.
a burst pair is a mark, space pairing. a mark is the on.. space is the off.. the first mark and space are the header.
This pair is what the receiver uses to make adjustments to the AGC so the reception of that code is going to be it's absolute best.

This is what gets used to determine the protocol.. well for most protocols we do. sometimes the header can be really close
to another protocol and if we used only that to determine the protocol we could get false decodes. So how I handle this is
I normalize the code to match the specification to as T. I check each burst pair to make sure that the mark and space
is +-10 % of the specification. if it is outside I kick the code back as not being a match and the program moves on to
the next decode to see if that one matches. This normalizing process is the core of getting the exact same code every
single time the button is pressed. The old plugin did not do this. so a minor change on one of the timings would produce a different code.

each burst pair represent 1 bit. there are 8 bits to a byte.. 8 bits represent a number from 0 to 255. that accounts for all possible combinations of 1's and 0's, for you folks that like to use calculators... 2 ^ 8 the 2 is the number of states (on and off) and the 8 is the number of bits.

so when an IR protocol says it is a 32 bit protocol it indeed is. However it is not used as a single number.. that number would be unmanageable to identify a device and the button pressed. there are 4294967296 possible combinations so a number between 0 and 4294967296..

a protocol separates the bits.. so for a 20 bit protocol you will have 8 bits for the command (button) 4 for the sub device and 6 for the device..
the device is more like a category so it would be AVR's or TV's the sub device narrows it down farther into say a defined period in time..It could be arranged so that the device and sub device will be a TV made in the 1990's. or the sub device could be a generational number..

so if you take the code above..

Code: Select all

8950 -4400 600 -500 650 -500 600 -500 600 -500 650 -500 600 -500 600 -500 600 -1700 550 -1650 600 -1650 600 -1600 550 -1700 550 -1700 550 -1650  550 -1650 600 -500 600 -500 650 -500 600 -1600 650 -1650 550 -1650 600 -500 600 -500 600 -1650 600 -1650 600 -1650 550 -500 600 -550 550 -550 600 -1650 600 -1600 600 -500 650 10452
and match it to this code.

Code: Select all

8250 -4700 520 -600 600 -500 600 -500 600 -550 650 -500 600 -650 600 -500 600 -1650 550 -1650 600 -1650 600 -1700 550 -1700 550 -1700 500 -1650  550 -1700 600 -500 600 -600 500 -500 600 -1600 650 -1650 650 -1650 600 -600 600 -500 600 -1700 500 -1650 600 -1650 550 -500 600 -500 550 -550 600 -1600 600 -1600 500 -600 600 10452
side by side

Code: Select all

8950 -4400 600 -500 650 -500 600 -500 600 -500 650 -500 600 -500 600 -500 600 -1700 550 -1650 600 -1650 600 -1600 550 -1700 550 -1700 550 -1650  550 -1650 600 -500 600 -500 650 -500 600 -1600 650 -1650 550 -1650 600 -500 600 -500 600 -1650 600 -1650 600 -1650 550 -500 600 -550 550 -550 600 -1650 600 -1600 600 -500 650 10452
8250 -4700 520 -600 600 -500 600 -500 600 -550 650 -500 600 -650 600 -500 600 -1650 550 -1650 600 -1650 600 -1700 550 -1700 550 -1700 500 -1650  550 -1700 600 -500 600 -600 500 -500 600 -1600 650 -1650 650 -1650 600 -600 600 -500 600 -1700 500 -1650 600 -1650 550 -500 600 -500 550 -550 600 -1600 600 -1600 500 -600 600 10452
these are 2 different IR codes yes???

nope.. they are in fact the same code.. if you normalize both of the using the numbers above you end up with this

Code: Select all

9000 -4500 560 -560 560 -560 560 -560 560 -560 560 -560 560 -560 560 -560 560 -1690 560 -1690 560 -1690 560 -1690 560 -1690 560 -1690 560 -1690  560 -1690 560 -560 560 -560 560 -560 560 -1690 560 -1690 560 -1690 560 -560 560 -560 560 -1690 560 -1690 560 -1690 560 -560 560 -560 560 -560 560 -1690 560 -1690 560 -560 560 -10452
which is a spot on perfect to the specification code. so long as all of the marks and spaces are +- 10% of the specification we then set it to be the specifications number.. no oddball codes getting produced using this mechanism..

The tolerance system I designed the user is going to be able to adjust it is preset to +-10% I have seen other decoders have it set to 25%.. by giving the user the ability to "dial" it in is going to allow for the best results.\
And wait there's more!!!
as batteries get weak in a remote so is the IR transmission.. This simple mechanism can be used to notify you that the batteries in your remote are going to shit.
EUREKA!!!

how does he think of these things!!!


Now back to the code normalization process..

Right now the plugin does not normalize.. You have to keep on pressing until you get x many codes that match identical... but what about all the other codes the remote sent out for the button?? are those no good??

No they are good codes and fall within the specification for the protocol. they just aren't good for the plugin.
if we normalize the code to be spot on with the specification then create the pronto code from that we are able to give the user a code that is going to work 100% of the time. because the receiver on the device is built to that specification..
This is a possible scenario that happens a lot.. say the n codes it matched are on the fringe of being a crap code.. this learned code can be +=10%.. how does that translate.. chances are that 1/2 of the time the code is blasted it is going to be over the line and will be considered a shit code by the device.
if we normalize it to be spot perfect to the speck there is no way the code will not work.. see where I am going with that.


Now here is a neat idea.. it is only going to require you to press the button a single time in order to carry this out.. Unless it was not able to decode the IR at all because there was IR bounce or whatever.. It is not usual to press a button and have it show up as a completely different button on the same remote.. if something occurs that distorts the IR. this is is called data corruption.. we have all had to deal with that headache.. and 99% of the time the data is not back to being the way it was before the corruption happened.. and that is trying to recover from a 1 and a 0 that is measured only as a high or a low to determine state..
It uses length of time along with state to determine a 1 or a 0.. and the time measurements we are talking here are micro seconds. 1/1000000 th of a second. and the receiver and the program has an accuracy down to 50us(microsecond). those numbers in the raw code are the actual us readings. divide them by 1000000 and it will tell you how long that space or mark is in seconds.


here is the above code in seconds

Code: Select all

0.009 -0.0045 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00056 0.00056 -0.00169 0.00056 -0.00169 0.00056 -0.00056 0.00056 -0.010452
if we take the spaces and flip them to be positive and then sum them all up we now have the total time it takesd to transmit that IR code.

0.078432 seconds
78.432 milliseconds(1000 in one second)

this is yet another mechanism that can be used to help in the identification process. if we take the lingest transmitting
time possible for a protocol and also the shortest couple that with the number of burst pairs the protocol is supposed to have
if the received code has the same number of pairs and the total time is between the shortest and longest time it passes the first step of verification.

There are enough mechanisms that can be used to properly identify an IR code.
there should be 0 codes being reported incorrectly. The current plugin did a very tiny amount of verification.

as a consumer we do not give a shit what the remote control belongs to or what type of device it originally operated or what generation of codes it is using.. all we want to know is what button did i press!!!.. readable strings that tell you specifically what button was pressed is a beautiful thing..can anyone tell me where this IP address goes.. right off the top of your head.. 172.217.1.206 hell no you can't.. It's one of googles web server ip addresses.. and why is EG spiting out hex numbers for remotes?? beats the shit out of me.... so I have been making lookup tables for the most common protocols and buttons.. and this is small enough to be stored locally with the plugin.. But the vastness of IR codes is insane. what was it.. 1956 was when the first IR remote was made.. something like that anyway..
I would not want to ship a plugin with that kind of data.. it's to much..

so I have decided to add an IR database to the EG webserver.
it is also going to allow a user to add codes and also retrieve them for blasting. This feature can be turned off and is not as requirement..It is only going to query for a code one time.. then that code is going to be stored locally. so basically point the remote and press each button on it.. then turn off the connection to the database.. the purdy name will still be produced!.. Tho the more people that add codes to the database the more effective it will become..



I am not going to be starting at ground 0 these are the numbers I am going to be starting off with.
I am starting off with

Code: Select all

number of codes:         114,410
number of devices:         2,168
number of manufacturers:     632 
number of sub devices:     3,410


and that is enough brain overload for you folks today... I wanted to give you this quick and dirty education of IR so you have a better understanding of how it works.
and now that you know how tragically inaccurate IR transmissions are you will think about the amount of time and the work involved in making a TV receive that IR signal and to not do something that it is not supposed to..

I also want you to have a better understanding of how much time I am spending to make it as close to 100% accurate as I
can. all i knew about IR remotes up until 3 weeks ago was that you point it at the device you want to have do something and you press a button.
I knew exactly 0 about IR transmissions and all of the different protocols. 0 about decoding raw IR data. and the different types of IR data like pronto codes and short pronto hex. RTL raw ir codes (this is the first code I posted) what are considered to be "raw codes" are RTL code that have the - removed for the spaces. so all numbers are positive.

Donate Button is below :shock: :smile:

Re: Microsoft MCE Remote - Vista and newer

Posted: Sun Jan 12, 2020 8:49 pm
by kkl
so I have decided to add an IR database to the EG webserver
Wow. :shock: That's quite an undertaking. I hope you're not starting out from scratch. The JP1 folks have been doing this for a couple of decades and have amassed quite the database. It would be quite a feat if you incorporated JP1 protocols. http://www.hifi-remote.com/forums/dload.php

Re: Microsoft MCE Remote - Vista and newer

Posted: Mon Jan 13, 2020 5:43 am
by kgschlosser
OK so the Vista+ portion of the code I can probably release in a new plugin. I am writing a whole new decoding system for EG. the one that is currently available is well. extremely lacking.. I am going to do some normalization or cleaning of the incoming and outgoing codes for the currently supported protocols This will stop the immediate issues of crappy learned codes, and inconsistent incoming codes. again that is only going to be for the currently supported protocols. If you have a remote that is producing an "Unknown" event for it I have no means to normalize those. that is because I do not have the specification for it. However... I might be able to take the burst pairs of the code which more times then not is going to follow a logical 1 mark and space also a logical 0 mark and space kind of arrangement. so what I can do is read the IR code. look at all of the marks and sort them into groups that are within +- 10% or so of each other.. and then average each group. do the same thing for the spaces. and then reinsert the marks and spaces using the averaged number. While it is not going to be a perfect solution I would say that it would stop the changing of the codes for the same button press by about 90% or so.

the new decoding system I am working on is going to use a combination of irp notation, pronto hex and RLC. I may even toss in there a conversion to globalcache.. I have to have a look and see what format other IR receiving plugins use. I may add others if the format is the same for more then a single plugin.

Re: Microsoft MCE Remote - Vista and newer

Posted: Mon Jan 13, 2020 6:32 am
by kgschlosser
OK I wrote the "cleaner" for the Unknown codes.

if I fed in these 2 codes. These are in fact the same IR code. There are variations in the timings between the 2 that is considered to be normal. But currently EG will spit out 2 different codes.

Code: Select all

8950 -4400 600 -500 650 -500 600 -500 600 -500 650 -500 600 -500 600 -500 600 -1700 550 -1650 600 -1650 600 -1600 550 -1700 550 -1700 550 -1650 550 -1650 600 -500 600 -500 650 -500 600 -1600 650 -1650 550 -1650 600 -500 600 -500 600 -1650 600 -1650 600 -1650 550 -500 600 -550 550 -550 600 -1650 600 -1600 600 -500 650 10452
8950 -4400 650 -550 650 -550 550 -500 650 -500 650 -500 600 -500 600 -500 600 -1700 550 -1650 600 -1650 600 -1600 550 -1700 600 -1650 550 -1650 550 -1650 600 -500 600 -500 650 -500 600 -1650 600 -1650 550 -1650 600 -550 600 -500 600 -1650 600 -1650 650 -1650 550 -500 600 -500 550 -550 600 -1650 600 -1600 600 -500 650 10452
You can see they appear to be different.

Here are the cleaned version of each one

Code: Select all

8950 -4400 600 -500 600 -500 600 -500 600 -500 600 -500 600 -500 600 -500 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -500 600 -500 600 -500 600 -1650 600 -1650 600 -1650 600 -500 600 -500 600 -1650 600 -1650 600 -1650 600 -500 600 -500 600 -500 600 -1650 600 -1650 600 -500 600 10450
8950 -4400 600 -500 600 -500 600 -500 600 -500 600 -500 600 -500 600 -500 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -500 600 -500 600 -500 600 -1650 600 -1650 600 -1650 600 -500 600 -500 600 -1650 600 -1650 600 -1650 600 -500 600 -500 600 -500 600 -1650 600 -1650 600 -500 600 10450
They are now identical

I was able to do this by taking each number and seeing if it was within the tolerances of an average of like grouped numbers. if it was I added it to tat group. If no group was found a new one was created. It does this again the code. and then also does it between the groups to check for any groups that should be apart of another

then for each group i average the group to get a base timing value then adjust the timing to fit into the sensitivity of 50us (specification). so round the thing to the nearest multiple of 50. and those are the marks and spaces i used to replace the ones in the actual code with. and how that is done is i create a high and a low by multiplying the timing by 1.10 and 0.90. +- 10% i run over the code and see if the number falls between the high and the low. if it does then set that timing to be the averaged one.


This is sloppy and was a quick and dirty to see if my theory would work.. and it did! I have to clean it up some. But you can run this if you want to see what it is going. I added a bunch of print statements to walk you through the steps. **WARNING** it prints out a heap of information (667 lines)

Code: Select all

def run(IRCODE):
    IRCODE = [int(item) for item in IRCODE.split(' ') if item.strip()]

    print ' '.join(str(item) for item in IRCODE)

    marks = []
    spaces = []

    print 'creating groups'
    for timing in IRCODE:
        if timing < 0:
            for space in spaces:
                avg = sum(space) / len(space)

                low = int(avg * 1.10)
                high = int(avg * 0.90)
                print 'SPACE   avg:', avg, 'high:', high, 'low:', low, 'timing:', timing
                if low <= timing <= high:
                    print 'SPACE   timing fits', space
                    space += [timing]
                    break
            else:
                print 'SPACE new group timing:', timing
                spaces += [[timing]]
        else:
            for mark in marks:
                avg = sum(mark) / len(mark)

                high = int(avg * 1.10)
                low = int(avg * 0.90)
                print 'MARK    avg:', avg, 'high:', high, 'low:', low, 'timing:', timing

                if low <= timing <= high:
                    print 'MARK    timing fits', mark
                    mark += [timing]
                    break
            else:
                print 'MARK  new group timing:', timing

                marks += [[timing]]
        print

    print
    print 'SPACES  ', spaces
    print 'MARK    ', marks
    marks2 = []
    spaces2 = []

    print
    print 'running second checks'
    # double check the groups for any possible straglers
    while marks:
        mark = marks.pop(0)
        avg_mark = sum(mark) / len(mark)
        for m in marks:
            avg = sum(m) / len(m)
            high = int(avg * 1.10)
            low = int(avg * 0.90)
            print 'MARK    avg:', avg, 'high:', high, 'low:', low, 'timing:', avg_mark
            if low <= avg_mark <= high:
                print 'MARK    timing fits', m
                m.extend(mark[:])
                break
        else:
            for m in marks2:
                avg = sum(m) / len(m)
                high = int(avg * 1.10)
                low = int(avg * 0.90)
                print 'MARK    avg:', avg, 'high:', high, 'low:', low, 'timing:', avg_mark

                if low <= avg_mark <= high:
                    print 'MARK    timing fits', m

                    m.extend(mark[:])
                    break
            else:
                marks2 += [mark[:]]
        print


    while spaces:
        space = spaces.pop(0)
        avg_space = sum(space) / len(space)
        for s in spaces:
            avg = sum(s) / len(s)
            high = int(avg * 1.10)
            low = int(avg * 0.90)
            print 'SPACE   avg:', avg, 'high:', high, 'low:', low, 'timing:', avg_space

            if low <= avg_space <= high:
                print 'SPACE   timing fits', s
                s.extend(space[:])
                break
        else:
            for s in spaces2:
                avg = sum(s) / len(s)
                high = int(avg * 1.10)
                low = int(avg * 0.90)
                print 'SPACE   avg:', avg, 'high:', high, 'low:', low, 'timing:', avg_space

                if low <= avg_space <= high:
                    print 'SPACE   timing fits', s
                    s.extend(space[:])
                    break
            else:
                spaces2 += [space[:]]

        print


    del marks[:]
    del spaces[:]

    print
    print 'SPACES  ', spaces2
    print 'MARK    ', marks2
    print

    print 'adjusting tolerance'
    # normalize the marks and spaces to a 50us tolerance
    for mark in marks2:
        mark = sum(mark) / len(mark)

        dif = mark % 50

        # print dif, mark
        if dif < 25:
            dif = -dif
        else:
            dif = 50 - dif

        print 'MARK    timing:', mark, 'diff:', dif

        mark += dif
        marks += [mark]

    # print
    # print
    print

    for space in spaces2:
        space = sum(space) / len(space)

        dif = space % 50

        # print dif, space


        if dif > 25:
            dif = 50 - dif
        print 'SPACE   timing:', space, 'diff:', dif

        space += dif
        spaces += [space]

    print
    print 'SPACES  ', spaces
    print 'MARK    ', marks
    print

    for i, timing in enumerate(IRCODE):
        for mark in marks:
            low = int(mark * 0.90)
            high = int(mark * 1.10)
            if low <= timing <= high:
                IRCODE[i] = mark
                break
        else:
            for space in spaces:
                high = int(space * 0.9)
                low = int(space * 1.10)
                if low <= timing <= high:
                    IRCODE[i] = space
                    break
            else:
                raise RuntimeError()



    print ' '.join(str(item) for item in IRCODE)
    return IRCODE


c1 = run('8950 -4400 600 -500 650 -500 600 -500 600 -500 650 -500 600 -500 600 -500 600 -1700 550 -1650 600 -1650 600 -1600 550 -1700 550 -1700 550 -1650 550 -1650 600 -500 600 -500 650 -500 600 -1600 650 -1650 550 -1650 600 -500 600 -500 600 -1650 600 -1650 600 -1650 550 -500 600 -550 550 -550 600 -1650 600 -1600 600 -500 650 10452')
print
print
c2 = run('8950 -4400 650 -550 650 -550 550 -500 650 -500 650 -500 600 -500 600 -500 600 -1700 550 -1650 600 -1650 600 -1600 550 -1700 600 -1650 550 -1650 550 -1650 600 -500 600 -500 650 -500 600 -1650 600 -1650 550 -1650 600 -550 600 -500 600 -1650 600 -1650 650 -1650 550 -500 600 -500 550 -550 600 -1650 600 -1600 600 -500 650 10452')
print
print 'code1 == code2:', c1 == c2

Re: Microsoft MCE Remote - Vista and newer

Posted: Mon Jan 13, 2020 6:38 am
by kgschlosser
I have been checking that mechanism against the protocols I know the marks and spaces for.. It appears to be working so well that is brings the code right into specification but without any knowledge of the protocol or what the timings are supposed to be as per the specification.

I may use this as a global thing instead of just for the Unknown codes. I am pleased at how well it works. I was only thinking about the Unknown codes.. This is going to remove quite a bit of added code in each of the protocols i have gotten done. a single mechanism able to handle correcting the timings for 20 protocols. SWEET!

Re: Microsoft MCE Remote - Vista and newer

Posted: Thu Jan 16, 2020 4:48 pm
by kgschlosser
OK I wanted to give everyone an update. I separated what I was working on into 2 pieces. I was going to combine them the decoder and the IR receiver interface but I would like to get you guys something that is working better then this currently is. Plus I could use some testers as well. I am having an issue that is very random I think it might be something wrong with the usb ports on my brand new main board (this is probably what it is) or it is an issue with the drivers. I get a sephamore error which is a low level windows error typically relating to device IO. I have been going over the code and changing things to see if it goes away. I have been doing this the past few days.. I am going to give up on trying to locate the issue because I do not think there is one in the code.

So last night into this morning I have been working on getting the thing tied in to EG which I have that portion done. I get the events like I am supposed to and they are consistent doesn't seem to waver at all. I have tested using 4 different IR protocols and it seems like it is good to go. I did ad a protocol decoding to it and that is the rc6. while I know it was already there it was not correct. I also believe that it is the most commonly used protocol.

I also added in that smoothing algorithm which has helped a large amount in having the repeat codes be stable. It's fast too. Faster then the way it was set up before I think. I never really measured the other one. It seem like this one is far quicker. probably because of the data type conversions needed in order to send the code over the named pipe.

for an MCE code the code is 107 milliseconds from start of code to start of code. and the spacing between my events is 109 milliseconds. so a 3 millisecond processing time. and I have to say at this point it is 98% accurate maybe higher. I am working on the learning portion at the moment. the dialogs and what have you.

The learning portion is a complete redesign. no more of this learning a single code at a time. a single dialog and you can learn all of the codes on a remote.. as an added bonus I also added the ability to name the codes. along with providing an event to use. and the ability to save it. YAY!!! no more pasting pronto codes!!!! These saved codes will be available from the transmit action

Only because of how involved a tree can get dealing with the remotes. I am going to use the same plugin name and GUID. the actions have been extended But they have been extended with default values. So your actions should work exactly as they are right now.

Re: Microsoft MCE Remote - Vista and newer

Posted: Fri Jan 17, 2020 5:18 am
by Crowley
Your progress report are interesting and I'm happy to help with testing if/when you need testers.

Re: Microsoft MCE Remote - Vista and newer

Posted: Fri Jan 17, 2020 10:19 am
by kgschlosser
when I get the learn portion working properly I will post a test version of it.

Re: Microsoft MCE Remote - Vista and newer

Posted: Tue Feb 25, 2020 8:51 pm
by Sem;colon
Hi Kevin,
Jep, the service was only transmitting or receiving.. and crashing every now and then.
Hated that thing, looking forward to it being gone! :mrgreen:
Keep up the good work! :)

Re: Microsoft MCE Remote - Vista and newer

Posted: Sat May 16, 2020 6:23 am
by Crowley
I was wondering if there has been any progress toward this. My eventghost config is working really good, the unreliability of MCE remote commands is the weakest link.

Re: Microsoft MCE Remote - Vista and newer

Posted: Sat May 16, 2020 7:57 am
by kgschlosser
yessum I have been working on it.

Because the decoders are built into the EG core I am going to have to update the decoders and include the updates in the next release of EG. The plugin is almost finished tho the accuracy is not going to improve until the decoders get updated. I have most of the updates done for the decoders I just have to put the whole package together and get the code added to the core.

I am trying to not break the current API for the plugin and I am finding it to be challenging.

Re: Microsoft MCE Remote - Vista and newer

Posted: Sun May 17, 2020 4:37 am
by Crowley
Thanks for the update!

Re: Microsoft MCE Remote - Vista and newer

Posted: Tue May 26, 2020 5:33 am
by kgschlosser
OK I have been putting some time in on this.

These are the protocols I have done
  • Aiwa
  • JVC
  • JVC-48
  • JVC-56
  • Kaseikyo (Japan Protocol)
  • MCE
  • Mitsubishi
  • Motorola
  • NCR-17
  • NEC
  • NECx
  • RC5
  • RC6
  • RC6-6-20
  • RCA
  • RCMM
  • RECS-80
  • Samsung-36
  • Sharp
  • Sony-12
  • Sony-15
  • Sony-20
  • Universal

I still have these protocols to add
  • Adnotam
  • AiraSync
  • Akai
  • Amino
  • Amino-56
  • Anthem
  • Apple
  • Archer
  • ArcTech
  • ArchTech-38
  • Barco
  • Blaupunkt
  • Bose
  • Bryston
  • CanalSat
  • CanalSatLD
  • Canon
  • Denon
  • Denon-K
  • DGTec
  • DirecTV
  • DishNetwork
  • DishPlayer
  • Elan
  • Emerson
  • Entone
  • F12
  • F32
  • Fujitsu
  • Fujitsu-56
  • GI 4DTV
  • GI Cable
  • GI RG
  • Grundig-16
  • Grundig-16-30
  • GWTS
  • GXB
  • Kaseikyo-56
  • Laser Tag
  • Lego
  • LG
  • Logitech
  • Lutron
  • Magi Quest
  • Mitsubishi-K
  • Mitsubishi Heavy
  • MWM
  • NEC1-48
  • NEC2-48
  • Nikai
  • Nokia
  • Nokia-12
  • Nokia-32
  • Panasonic
  • Panasonic-2
  • Pioneer
  • Samsung
  • Sanyo
  • Sheerwood
and more on top of that I got tired of typing them out. LOL

I have a framework all laid out now so it should go alot faster to add the protocols. I also set it up to normalize the codes for optimal transmitting and learning. I also added encoding on top of the decoding. So if you wanted to you can use a device id, sub device id and a function number and it will build the code for you.

For the protocols where I was able to locate proper mappings for the button names I have added those. I would ultimately like to set up a repository where learned codes can be stored with friendly names. I have a HEAP of codes already stashed but I need the decoders in place in order to get the protocol, device, sub device and function in order to do a name lookup. I am getting there. Connecting the the EG server is going to be optional and it would only make the connection each time a new ir code is received. then it will store the name locally so constant queries will not have to be done all the time. When learning a code I will have the option for the user to be able to add the code to the database. It's always nice to share :smile:

Re: Microsoft MCE Remote - Vista and newer

Posted: Wed May 27, 2020 5:51 am
by kgschlosser
I added 8 more protocols bringing the grand total up to 31
  1. Aiwa
  2. JVC
  3. JVC-48
  4. JVC-56
  5. Kaseikyo (Japan Protocol)
  6. MCE
  7. Mitsubishi
  8. Motorola
  9. NCR-17
  10. NEC
  11. NECx
  12. RC5
  13. RC6
  14. RC6-6-20
  15. RCA
  16. RCMM
  17. RECS-80
  18. Samsung-36
  19. Sharp
  20. Sony-12
  21. Sony-15
  22. Sony-20
  23. Universal
  24. Akai
  25. Denon-K
  26. Fujitsu
  27. Panasonic
  28. Sharp-DVD
  29. Teac-K
  30. Kaseikyo-56
  31. ITT

Re: Microsoft MCE Remote - Vista and newer

Posted: Thu May 28, 2020 1:05 pm
by kgschlosser
OK folks so here is an updated list of what I have added. I still have to run through testing of the protocols but I am pretty sure the majority will work without issue. I will have to make some tweaks to get the ones working that aren't.
  1. 48-NEC2
  2. AdNotam
  3. Aiwa
  4. Akai
  5. Amino
  6. Archer
  7. Barco
  8. Blaupunkt
  9. Bose
  10. Bryston
  11. CanalSat
  12. CanalSatLD
  13. Denon
  14. Denon-K
  15. Dishplayer
  16. Dish_Network
  17. Elan
  18. Emerson
  19. F32
  20. Fujitsu
  21. Fujitsu-56
  22. G.I.4DTV
  23. G.I.RG
  24. Humax 4Phase
  25. JVC
  26. JVC-48
  27. JVC-56
  28. Kaseikyo
  29. Kaseikyo56
  30. Konka
  31. Lutron
  32. Logitech
  33. Matsui
  34. MCE (RC6-6-32)
  35. Metz19
  36. Mitsubishi
  37. Mitsubishi-K
  38. Motorola
  39. NCR-17
  40. NEC1
  41. NEC2
  42. NECx1
  43. NECx2
  44. Pace MSS
  45. Panasonic
  46. Panasonic2
  47. Panasonic_Old
  48. PCTV
  49. pid-0001
  50. pid-0003
  51. pid-0004
  52. Pioneer
  53. Proton
  54. RC5
  55. RC5-7F
  56. RC5-7F-57
  57. RC5x
  58. RC6
  59. RC6-6-20
  60. RCA
  61. RCMM
  62. RECS-80
  63. Revox
  64. Samsung20
  65. Samsung36
  66. Sampo
  67. ScAtl-6
  68. Sharp
  69. SharpDVD
  70. SIM2
  71. Solidtek20
  72. Somfy
  73. Sony8
  74. Sony12
  75. Sony15
  76. Sony20
  77. StreamZap
  78. StreamZap-57
  79. Sunfire
  80. Teac-K
  81. Thomson
  82. Thomson7
  83. Universal
  84. Velleman
  85. Viewstar