Closed kdschlosser closed 4 years ago
bengtmartensson
commented
4 years ago Thanx for the issue. I transferred it and allowed myself to change the title. I have made a question here, where the real protocol experts sit, lets see what comes out.
kdschlosser
commented
4 years ago no worries m8, I stumbled across that document and say that protocol in it and I didn't recall seeing it in your list of available protocols. I then checked to see if possibly the protocol could have been named something different so I checked all of the IRP notations to see if any of them has a 512us half bit time and none of them do.
You seem to be the kind of person that will add something just for the sake of completeness, even tho it may not get used.
I have a python implementation of the protocol, It was added to an open source application that I am the manager of a long long time ago. I do not know if it is correct or not but you are more then welcome to have a peek at it.
https://github.com/EventGhost/EventGhost/tree/master/eg/Classes/IrDecoder
I also tried searching for the chip numbers they mention, while I did come up with a lot of diagrams/schematics/datasheets nothing that outlined the protocol except the single document I posted the link to already.
bengtmartensson
commented
4 years ago In the light of 3FG's answer in the hifi-remote forum (actually, only the modulation frequency differs, and that is within the error margin) , I think the best solution is to add "Motorola" as alternative name to "Blaupunkt".
I have a python implementation of the protocol, It was added to an open source application that I am the manager of a long long time ago. I do not know if it is correct or not ...
Why don't you have your python class(es) to generate stuff to a file, and feed that to IrpTransmogrifier, using the --input option to decode?
kdschlosser
commented
4 years ago it takes to long for IrpTransmogrifier to start up. and to leave it running consumes to much resources because of the JVM. If IrpTransmogrifier was coded in c and I could access it as a shared library (dll) then I could use it. starting processes on Windows using Python can have some pretty undesirable outcomes like orpaned processes and things of that nature. so I wanted to steer clear of doing that.
I was in the process of writing an IRP decoder and quickly realized that there are to many variations to how the notation gets used. The amount of code needed to write a parser that worked would have been more then doing what I ended up doing and writing a class for each protocol that handles encoding and decoding.
It's actually kind of funny because I could now write a much simpler parser and have it fill in the "blanks" that are needed and it would work for 95% of the protocols that are known and have IRP notation written for them. It is easier to debug a protocol when code is written for only that protocol then having to deal with a parsing process.
once I managed to get the operators like ~ working properly it because easier to do.
I still have to figure out hyow to deal with these kinds of timings and how to apply them to the RLC <-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1> <1|-1>
with <-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1> for a timing I had thought each timing would represent 0, 1, 2 or 3. But I do not know how to combine 2 bits together to make up day a device. would I just add them together?? IDK. or perhaps the timings are telling me that a burst pair is actually 4 bits. I have not dove into it yet to figure it out.
The Motorola protocol.
http://read.pudn.com/downloads157/sourcecode/embed/701593/docs/IR%20Formats%202.PDF i believe the irp for it would be.
It's hard to make out how the split between device and function take place. They state there are 9 bits and 1 start bit. on one of the images it has bit0 ..... bit 6 labeled as command leaving 2 bits unaccounted for which I believe to be the device , I am not entirely sure tho. This is an older protocol, I believe from the late 1980's or earlier.