[quote author="JTR"] For some reason the 0xFF, 0xFF is being written out as 377 and this translates to 0x01 (SUMP RUN) when it is sent to the serial port.
Looks like the compiler is not handling xFF correctly. I wonder what happens if you change that to 0xFF?[/quote]
Ahem, 377 is just 0xFF in octal ;-)
[quote author="JTR"] It does seem that the problem is a mis-porting of the C compiler's serial_read library function (and/or the USB CDC driver) [/quote]
I checked, serial_read is part of IRToyRecPlay, not the C library, and it's a quick and dirty port of a windows version by the looks of it. Its behaviour is to keep trying to receive the number of bytes it is asked to, until a time-out occurs. So calling it with sizeof(buf) does seem to be a bug, but the fact that it ends up receiving a bunch of garbage before it times out means that either the Irtoy is suffering from bad ir noise and interpreting that as data, or the CDC-ACM driver is making the garbage up.
[quote author="ian"] This is extra strange before in all of it I never see the terminator 0xff 0xff, so it is like the data goes constantly. [/quote]
Yes, when close to an lcd screen or directly under fluorescent lighting there is so much IR noise that Irtoy will stream continuousy, without ever timing out. The led flashing continuously seems to rule out it being a driver artefact.
[33069.845890] tty_port_close_start: tty->count = 1 port count = 0. [33069.853002] tty_port_close_start: tty->count = 1 port count = 0.
[/quote]
This is due to annoying behaviour of the linux cdc acm driver. What happens is, if a device is streaming data when no user app has the corresponding acmx port open, the driver craps out with these messages. In the lirc patch, I tried to mitigate this by always going back to irman mode when closing the device, as the irtoy does not stream so much data in that mode. The real fix would have to be done in the linux cdc driver, but from what I gather it is not considered a bug in the driver, but in the device that is streaming unsollicited data. Go figure...
Possibly you are running into an annoying issue with the linux cdc-acm driver (although on my system the log messages when this occurs are different). To do a quick test, can you add a line at the very end of function main() to get it like this
sleep(2); // linux: sleep for 2 secs #endif //<-------- add next line ----------> serial_write( fd, "xFFxFFx00x00x00x00x00", 7); //---------- end of change ---------> serial_close(fd); FREE(param_port);
recompile, and then test again using recording, eg something like
[quote author="tbshk"] usb 1-3.1: device descriptor read/64, error -71 usb 1-3.1: device descriptor read/64, error -71 [/quote]
Ouch that´s nasty. So just to confirm, when you plug it in, it always works? It will only fail after some send/receive activity has taken place? Enumeration looks normal when you plug it in and then do dmesg | grep -i usb ?
[quote author="const"] irrecord does two different conf files for the same remote panel. First big in raw mode and it work correct. Second small, with it, two of the 21 buttons do not work and the rest give multiple commands on one click.[/quote]
That kind of problem with irrecord happens from time to time, mainly due to the enormous amount of guesswork irrecord does in "cooked" mode. However, I would like to make sure it's not a driver issue, can you let us know what remote control you used? Also, check the lirc website for conf files for your remote.
Do you have a file lirc or lircd in /etc/init.d at all? Also, try starting lircd directly as I indicated above, at least it will allow you to test if your newly compiled lircd works.
making sure you execute the lircd you compiled, not the one from your distribution. After starting lircd, test with irw to see if it recognizes your remote.
[quote author="albuquerque13"] I have attached the conf file for another remote that I tried. This one is the remote of a LG Flatron TV.[/quote]
I happen to own an LG Flatron, and was able to control it with your conf file, Lirc with the irtoy driver and V20 firmware. I am wondering, are you sure you have the latest (release) version of the V20 fw loaded? I think there have been some release candidates that had problems transmitting.