EventGhost

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 ) 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..
and match it to this code. side by side 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 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 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


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

so I have decided to add an IR database to the EG webserver

Wow. 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

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.

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.
You can see they appear to be different.

Here are the cleaned version of each one 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)

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!

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.

Your progress report are interesting and I'm happy to help with testing if/when you need testers.

when I get the learn portion working properly I will post a test version of it.

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!
Keep up the good work!