FTDI IR Blaster not working

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

FTDI IR Blaster not working

Jasper
Good day All,
 I have built an FTDI IR blaster as per Alberts post (http://www.huitsing.nl/irftdi/) using an FTDI cable (confirmed legit).
 I setup LIRC 0.9.0 from Ubuntu Wily with a hardware conf as follows:
#Chosen IR Transmitter
TRANSMITTER="None"
TRANSMITTER_MODULES=""
TRANSMITTER_DRIVER="ftdi"
TRANSMITTER_DEVICE="serial=AI049VIJ,output=2"
TRANSMITTER_SOCKET=""
TRANSMITTER_LIRCD_CONF=""
TRANSMITTER_LIRCD_ARGS=""

And am using a XXD306 (Pioneer_XXD3067) remote definition and this has worked fine with a homebrew serial transmitter.

I can confirm that the IR LED flashes (using my phones camera), but the amplifier (Pioneer VSX-D812) does not respond.
I have tried different LED's, the same LED in the currently working serial trasmitter, different resistors, different remote definitions. No joy 8(

I contacted Albert and he suggested that I use his 'test.c' which I compiled as:
gcc test3.c -o test3 $(pkg-config --cflags --libs libftdi1)
On my scope I did not get a nice 38kHz signal - the carrier frequency bounced around between 32 and 40kHz.
Albert had no more suggestions.

I see there is active development on the FTDI driver/plugin and hope that someone here may be able to give me some clues to help get this going.

I tried comiling and running the latest from git but could not figure out the correct syntax - options seemed to have changed a lot since 0.9 8)
I tried things like
LD_LIBRARY_PATH=/opt/lib sudo -E /opt/sbin/lircd --driver=ftdi --device=auto  --driver-options=serial=AI049VIJ,output=2 -n
Anyway, none of that worked.

The poor server hosting the serial blaster is dying and needs to be replaced, none of the machines I have to replace it have serial!

Cheers

Jasper
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Bengt Martensson-2
On 04/20/16 20:54, Jasper wrote:
> Good day All,
>   I have built an FTDI IR blaster as per Alberts post
> (http://www.huitsing.nl/irftdi/) using an FTDI cable (confirmed legit).

...

> I tried comiling and running the latest from git but could not figure out
> the correct syntax - options seemed to have changed a lot since 0.9 8)
> I tried things like
> LD_LIBRARY_PATH=/opt/lib sudo -E /opt/sbin/lircd --driver=ftdi --device=auto
> --driver-options=serial=AI049VIJ,output=2 -n
> Anyway, none of that worked.
>
> The poor server hosting the serial blaster is dying and needs to be
> replaced, none of the machines I have to replace it have serial!

Sorry, I cannot help you with the problem as you state it. But since you
are buying new stuff anyhow, how do you come with the conclusion that
using the the most primitive bit-banging technology drivers is a good
idea? Having the PC deliver a new value every few new hundred
microseconds (if using hardware carrier), or every 13 microseconds
(generating a 38kHz carrier in software) is really not something that
belongs to this century. Albert's driver is supposed to generate the
carrier in hardware, but -- as you say -- it seems not to be working
well. A TSOP xxx38 receiver will have no major problems with 36 - 40
kHz, but with larger deviations, it is a problem.

Building the current Lirc is really not that hard, there are
descriptions elsewhere.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Jasper
Bengt Martensson-2 wrote
But since you
are buying new stuff anyhow, how do you come with the conclusion that
using the the most primitive bit-banging technology drivers is a good
idea? Having the PC deliver a new value every few new hundred
microseconds (if using hardware carrier), or every 13 microseconds
(generating a 38kHz carrier in software) is really not something that
belongs to this century. Albert's driver is supposed to generate the
carrier in hardware, but -- as you say -- it seems not to be working
well. A TSOP xxx38 receiver will have no major problems with 36 - 40
kHz, but with larger deviations, it is a problem.
Bengt what hardware would you suggest instead please?

Bengt Martensson-2 wrote
Building the current Lirc is really not that hard, there are
descriptions elsewhere.
Building is not the problem, it is/was starting with the right options etc.
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Bengt Martensson-2
On 04/24/16 22:10, Jasper wrote:

> Bengt Martensson-2 wrote
>> But since you
>> are buying new stuff anyhow, how do you come with the conclusion that
>> using the the most primitive bit-banging technology drivers is a good
>> idea? Having the PC deliver a new value every few new hundred
>> microseconds (if using hardware carrier), or every 13 microseconds
>> (generating a 38kHz carrier in software) is really not something that
>> belongs to this century. Albert's driver is supposed to generate the
>> carrier in hardware, but -- as you say -- it seems not to be working
>> well. A TSOP xxx38 receiver will have no major problems with 36 - 40
>> kHz, but with larger deviations, it is a problem.
>
> Bengt what hardware would you suggest instead please?

For taking the microseconds stress off the main CPU, you need something
with a dedicated micro processor. For sending "all" signals, you need
something with the driver flags a and s. Let's try the ones in current Lirc:

$ lirc-lsplugins | grep -- -as

audio               -as   /usr/local/lib/lirc/plugins/audio.so
commandir           -as   /usr/local/lib/lirc/plugins/commandir.so
file                -as   /usr/local/lib/lirc/plugins/file.so
ftdi                -as   /usr/local/lib/lirc/plugins/ftdi.so
girs                -as   /usr/local/lib/lirc/plugins/girs.so
iguanaIR            -as   /usr/local/lib/lirc/plugins/iguanaIR.so
irtoy               -as   /usr/local/lib/lirc/plugins/irtoy.so
uirt2_raw           -as   /usr/local/lib/lirc/plugins/uirt2_raw.so
usb_uirt_raw        -as   /usr/local/lib/lirc/plugins/uirt2_raw.so

Here audio and ftdi are not sensible, file for debugging only. CommandIR
hardware probably no longer available, Iguana, IrToy and usb/uirt (the
two last entries are for the same hardware) are more-or-less available.
Girs, which is my creation, is (for the time being) essentially Arduino,
see http://harctoolbox.org/arduino_nano.html, use the fixed driver here
https://sourceforge.net/u/bengtmartensson/lirc/ci/driver-fixes/tree/ 
(merge request pending).

I can help with Girs and IrToy, Alec with Iguana.

There may be more alternatives using the driver with the well-chosen
name "default", like mce.


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Albert Huitsing-2
Hi

> For taking the microseconds stress off the main CPU, you need
> something with a dedicated micro processor.

just to stop spreading some non-sense here: the FTDI driver does *not*
require the CPU to 'time' 38kHz through bitbanging. The FTDI chip does
this (or should) on it's own: it is used as a shift-register with USB
connection.

> Here audio and ftdi are not sensible, file for debugging only.

how do you come to that conclusion? Did you try it yourself?

Albert

--
*** NEW TELEPHONE NUMBER !! ****
  new number = +31 (0)852010196
********************************

Albert Huitsing ([hidden email])
Huitsing Embedded Systems
Dr. Mondenweg 5
7831 JA  Nw. Weerdinge
+31-(0)852010196
http://www.huitsing.nl
"conformity is the uncomfortable feeling of wearing
  somebody else's clothes; even when they don't fit"


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

lirc-5
In reply to this post by Jasper
On Wed, 20 Apr 2016, at 19:54, Jasper wrote:
> I see there is active development on the FTDI driver/plugin and hope that
> someone here may be able to give me some clues to help get this going.

We've found the FT232R to have unreliable timing in bitbang mode.
Depending on the receiver this can cause missed keypresses.  I would
recommend the FT230X series instead
http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_UMFT201_220_230XB.pdf
.  The FT232R is particularly unreliable with baud-rates other than
65536.

I've written a new driver called ftdix which takes advantage of the
reliable bitbang timing on the FT230X chips by adjusting the baud-rate
according to the carrier frequency.  This helps to improve reliability
and resource consumption.  I'll be proposing it in a patch once I've got
my previous 4 patches to the FTDI driver reviewed and upstream.  I'm
guessing the maintainer must be on holiday or busy at the moment.  You
can see it here:
https://github.com/stb-tester/lirc/commit/85a94b9ddd37ff4efbcae5edf54f0e9b499a2dbc

Regarding Bengt's concerns: the FT230X has a 512B transmit buffer.  At
38kHz carrier frequency that's 6.7ms worth of data, more than enough
time for the host to send more data to the chip.  Nonetheless I've built
the new driver to put itself into SCHED_FIFO scheduling mode when
transmitting to avoid buffer underruns even under load.  It's proved
remarkably reliable in testing - I've put 230000 key-presses through it
with no misses and low resource usage.

Thanks

Will

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Albert Huitsing-2
Hello Will,

thanks for some clarification on this matter here !

now I must find some time to update my irftdi page to reflect these new
findings :-)

Albert

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Bengt Martensson-2
In reply to this post by Albert Huitsing-2
On 04/25/16 11:00, Albert Huitsing wrote:
> Hi
>
>> For taking the microseconds stress off the main CPU, you need
>> something with a dedicated micro processor.
>
> just to stop spreading some non-sense here: the FTDI driver does *not*
> require the CPU to 'time' 38kHz through bitbanging.

I have not made that statement; instead I wrote

 >> Albert's driver is supposed to generate the carrier in hardware,

so shall we leave the confrontation mode ... ?

> The FTDI chip ...  it is used as a shift-register with USB
> connection.

This is new to me. But the code says (line 5-7)

* Mode2 receiver + transmitter using the bitbang mode of an FTDI
* USB-to-serial chip such as the FT232R, with a demodulating IR receiver
* connected to one of the FTDI chip's data pins -- by default, D1 (RXD).

and you web page about the same, as well as doc/plugindocs/ftdi.html.
So, since you are describing it as "bitbang" yourself, it appears to be
a documentation problem.

So why don't you (and/or Will) write some documentation of this?

Greetz,

Bengt


PS. Nice to see you back Alec!

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Alec Leamas
In reply to this post by lirc-5


On 25/04/16 11:38, Will Manley wrote:

> On Wed, 20 Apr 2016, at 19:54, Jasper wrote:
>> I see there is active development on the FTDI driver/plugin and hope that
>> someone here may be able to give me some clues to help get this going.
> We've found the FT232R to have unreliable timing in bitbang mode.
> Depending on the receiver this can cause missed keypresses.  I would
> recommend the FT230X series instead
> http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_UMFT201_220_230XB.pdf
> .  The FT232R is particularly unreliable with baud-rates other than
> 65536.
>
> I've written a new driver called ftdix which takes advantage of the
> reliable bitbang timing on the FT230X chips by adjusting the baud-rate
> according to the carrier frequency.  This helps to improve reliability
> and resource consumption.  I'll be proposing it in a patch once I've got
> my previous 4 patches to the FTDI driver reviewed and upstream.  I'm
> guessing the maintainer must be on holiday or busy at the moment.  You
> can see it here:
> https://github.com/stb-tester/lirc/commit/85a94b9ddd37ff4efbcae5edf54f0e9b499a2dbc
>
>
Hi,

I'm back again. Sorry for being unavailable for a too long time.

Anyway, I would be happy to merge this patch. Two things would make it
easier:

- If you added a simple doc page in doc/plugindocs, use the existing
ftdi.html as template. Preferably, also add a reference to ftdix in the
ftdi page.
- If you submitted it as a proper sourceforge merge request or filed a
bug and attached the patch.



Cheers!

--alec

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Jasper
In reply to this post by Bengt Martensson-2
Thank you all for _all_ the valuable input.
 Bengt: I have a spare nano so will construct your project this week, I will only use the transmit side and and as-close-to 68 ohm resistor as I can find (hopefully will have done this by wednesday).
 Again as in original post: If I am using 0.9.4 (or whatever is the latest git) and the lirc.service for systemd (brave new world...) how do I specify the hardware? Is it the same as old, with a hardware.conf?
No doubt due the the plethora of other sub-serial devices it will randomly be on /dev/ttyUSB2 ... or 1 or 0 8)

Alec:
 I am glad that what you see is not too different to me - maybe my scope skills are not way off. I wish I could get nice pictures like you do - video capture of the scopes screen just isnt the same... or useful...
 But I am concerned that I am experiencing a problem. If it is as bad as I have it surely others would have piped up by now. A lost signal or two is not the end of the world, but nothing - ever - seems a bit odd.

Will:
 I have to get some bits from element14 so an FTDI230x breakout board will help push me over the free shipping limit 8) Do you recommend a model? WE or NE (I2C)
 I guess I just replace the ftdi.c in git repo with the one from your git repo and bobs you uncle it all works?

Thanks for ending all happy as 8) Better get some more nano's - as for my new years resolution of going to STM32 it just cant happen when a nano is $6 delivered and just so damn easy...

I had to get up three times today to go turn the amp on by hand - this madness must stop!
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Bengt Martensson-2
On 04/25/16 12:40, Jasper wrote:
> Thank you all for _all_ the valuable input.
>   Bengt: I have a spare nano so will construct your project this week, I will
> only use the transmit side and and as-close-to 68 ohm resistor as I can find
> (hopefully will have done this by wednesday).

Good luck!
>   Again as in original post: If I am using 0.9.4 (or whatever is the latest
> git) and the lirc.service for systemd (brave new world...) how do I specify
> the hardware? Is it the same as old, with a hardware.conf?

I recommend, at least until the deployment phase, just starting lircd
from the command line, as

lircd -n -l -L /tmo/lircd.log --debuglevel=... --driver=... --device=...

i.e. without systemd, hardware.conf, and in particular without
lirc_options.conf. When it is time for deployment, then that stuff may
come in handy.

> No doubt due the the plethora of other sub-serial devices it will randomly
> be on /dev/ttyUSB2 ... or 1 or 0 8)

It is not "random", it is the lowest unused. If that is a problem, see
http://harctoolbox.org/arduino_nano_part2.html#Appendix.+Configuration+of+udev+for+Linux

There are nano-clones to be had at ebay or aliexpress for < 3€/$. Buy 5
while you are at it...

Greetz,

Bengt

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Jasper
Bengt:
 Your arduino code does not compile. OMG that Arduino IDE is aweful! do you hava makefile so we can just make and upload with avrdude? I never used Arduino IDE, did it all in C - for better or worse 8)

The error is:
In file included from GirsLite.cpp:19:0:
/usr/share/arduino/libraries/GirsLib/LedLcdManager.h: In static member function ‘static void LedLcdManager::lcdPrint(const __FlashStringHelper*, boolean, int, int)’:
/usr/share/arduino/libraries/GirsLib/LedLcdManager.h:99:27: error: call of overloaded ‘String(const __FlashStringHelper*&)’ is ambiguous
         String string(pstr);
                           ^
/usr/share/arduino/libraries/GirsLib/LedLcdManager.h:99:27: note: candidates are:
In file included from /usr/share/arduino/hardware/arduino/cores/arduino/Arduino.h:192:0,
                 from /usr/share/arduino/libraries/Infrared4Arduino/InfraredTypes.h:4,
                 from /usr/share/arduino/libraries/GirsLib/Tokenizer.h:4,
                 from /usr/share/arduino/libraries/GirsLib/LedLcdManager.h:4,
                 from GirsLite.cpp:19:
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:70:11: note: String::String(long unsigned int, unsigned char) <near match>
  explicit String(unsigned long, unsigned char base=10);
           ^
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:70:11: note:   no known conversion for argument 1 from ‘const __FlashStringHelper*’ to ‘long unsigned int’
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:69:11: note: String::String(long int, unsigned char) <near match>
  explicit String(long, unsigned char base=10);
           ^
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:69:11: note:   no known conversion for argument 1 from ‘const __FlashStringHelper*’ to ‘long int’
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:68:11: note: String::String(unsigned int, unsigned char) <near match>
  explicit String(unsigned int, unsigned char base=10);
           ^
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:68:11: note:   no known conversion for argument 1 from ‘const __FlashStringHelper*’ to ‘unsigned int’
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:67:11: note: String::String(int, unsigned char) <near match>
  explicit String(int, unsigned char base=10);
           ^
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:67:11: note:   no known conversion for argument 1 from ‘const __FlashStringHelper*’ to ‘int’
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:66:11: note: String::String(unsigned char, unsigned char) <near match>
  explicit String(unsigned char, unsigned char base=10);
           ^
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:66:11: note:   no known conversion for argument 1 from ‘const __FlashStringHelper*’ to ‘unsigned char’
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:65:11: note: String::String(char) <near match>
  explicit String(char c);
           ^
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:65:11: note:   no known conversion for argument 1 from ‘const __FlashStringHelper*’ to ‘char’
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:60:2: note: String::String(const String&) <near match>
  String(const String &str);
  ^
/usr/share/arduino/hardware/arduino/cores/arduino/WString.h:60:2: note:   no known conversion for argument 1 from ‘const __FlashStringHelper*’ to ‘const String&’


Versions:
avr-libc                                                      1:1.8.0+Atmel3.5.0-1
avrdude                                                     6.2-5
binutils-avr                                                2.25+Atmel3.5.0-2
gcc-avr                                                     1:4.9.2+Atmel3.5.0-1
gdb-avr                                                     7.7-2build1
arduino                                                     2:1.0.5+dfsg2-4
arduino-core                                              2:1.0.5+dfsg2-4
(Ubuntu Xenial)

Damn, thought I would get it done before work this morning 8)
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Bengt Martensson-2
On 04/25/16 20:42, Jasper wrote:
> Bengt:
>   Your arduino code does not compile. OMG that Arduino IDE is aweful! do you
> hava makefile so we can just make and upload with avrdude? I never used
> Arduino IDE, did it all in C - for better or worse 8)

I am not a fan of it either; this should be pretty clear from the files
on GitHub and on my website. My opinion: would be much better if they
had used either Eclipse or Netbeans.

There is a Makefile, but it "only" builds a PC version.

> Versions:
...
> arduino                                                     2:1.0.5+dfsg2-4
> arduino-core                                              2:1.0.5+dfsg2-4

This belongs in a museum. Please download 1.6.8 from arduino.cc. Will
probably fix the problem.

> (Ubuntu Xenial)

Shall we tar-and-feather them?

> Damn, thought I would get it done before work this morning 8)

Well, my guide
http://localhost:8888/arduino_nano_part2.html#Compiling+the+sources 
explicitly states to get the latest Arduino IDE...

Greetz,

Bengt


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Jasper
Thanks Bengt,
 Updating to the latest Arduino did fix it.

But I have some questions about how LIRC is behaving with this hardware (Which is working it seems).
Using lirc-git (latest) and prefix=/usr etc.
 I have an lirc_options.conf as:
[lircd]
nodaemon        = False
driver          = girs
device          = /dev/ttyUSB1
output          = /run/lirc/lircd
pidfile         = /run/lirc/lircd.pid
plugindir       = /usr/lib/lirc/plugins
permission      = 666
allow-simulate  = No
repeat-max      = 600

[lircmd]
uinput          = False
nodaemon        = False

and start the daemon successfully with systemd or manually as lircd -n
BUT
When I send using
irsend SEND_ONCE -d/run/lirc/lircd --count=10 ....
two bad things happen:
 1) I get broadcast messages on all open termianls - tons of unbelievable spew! No wonder &>/dev/null didnt work!
 2) I get tons of these errors in syslog: irsend[28898]: fill_string: timeout, and a random number of events are registered on the amplifier (ie count 10 volume up reulsts in 5-7 depending).

Other than that it is _working_.
Any ideas how to fix this?

Cheers

Jasper
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Bengt Martensson-2
On 04/26/16 12:59, Jasper wrote:
> Thanks Bengt,
>  Updating to the latest Arduino did fix it.

Gr8!

> But I have some questions about how LIRC is behaving with this hardware
> (Which is working it seems).
> Using lirc-git (latest) and prefix=/usr etc.
>  I have an lirc_options.conf as:
> [lircd]
> nodaemon        = False
> driver          = girs
> device          = /dev/ttyUSB1

Probably a bad idea; if you have more than one device, consider using
udev to get a predictable name, see
http://harctoolbox.org/arduino_nano_part2.html#Appendix.+Configuration+of+udev+for+Linux

..

> and start the daemon successfully with systemd or manually as lircd -n
> BUT
> When I send using
> irsend SEND_ONCE -d/run/lirc/lircd --count=10 ....
> two bad things happen:
>  1) I get broadcast messages on all open termianls - tons of unbelievable
> spew! No wonder &>/dev/null didnt work!
>  2) I get tons of these errors in syslog: irsend[28898]: fill_string:
> timeout, and a random number of events are registered on the amplifier (ie
> count 10 volume up reulsts in 5-7 depending).

I have not seen that myself, and do not know the answer :-\. I do not
like syslog myself... See the posts from Helen Foster, about a month
ago. Possibly Alec has an idea?

Greetz,

Bengt


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Alec Leamas
In reply to this post by Jasper


On 26/04/16 12:59, Jasper wrote:

> Thanks Bengt,
>   Updating to the latest Arduino did fix it.
>
> But I have some questions about how LIRC is behaving with this hardware
> (Which is working it seems).
> Using lirc-git (latest) and prefix=/usr etc.
>   I have an lirc_options.conf as:
> [lircd]
> nodaemon        = False
> driver          = girs
> device          = /dev/ttyUSB1
> output          = /run/lirc/lircd
> pidfile         = /run/lirc/lircd.pid
> plugindir       = /usr/lib/lirc/plugins
> permission      = 666
> allow-simulate  = No
> repeat-max      = 600
>
> [lircmd]
> uinput          = False
> nodaemon        = False
>
> and start the daemon successfully with systemd or manually as lircd -n
> BUT
> When I send using
> irsend SEND_ONCE -d/run/lirc/lircd --count=10 ....
> two bad things happen:
>   1) I get broadcast messages on all open termianls - tons of unbelievable
> spew! No wonder &>/dev/null didnt work!
>   2) I get tons of these errors in syslog: irsend[28898]: fill_string:
> timeout, and a random number of events are registered on the amplifier (ie
> count 10 volume up reulsts in 5-7 depending).
>
> Other than that it is _working_.
> Any ideas how to fix this?
>
Hi!

Hard to tell how to fix, not knowing what's it all about ;) The
fill_string message indicates that there is some problem reading data
from the lircd socket.  Some questions:

- Have you installed lirc into standard locations i. e., something like
"make --prefix=/usr; make install"?
- What is the exact irsend command line you are running?
- Is there anything more in syslog?
- Is there anything more in syslog if you raise the loglevel to 'debug'?
- Are you using the master branch or the release-0_9_4 branch?
- If on master, does switching to release-0_9_4 make any difference?


Cheers!

--alec



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

lirc-5
In reply to this post by Alec Leamas
On Mon, 25 Apr 2016, at 12:37, Alec Leamas wrote:

> On 25/04/16 11:38, Will Manley wrote:
> > On Wed, 20 Apr 2016, at 19:54, Jasper wrote:
> >> I see there is active development on the FTDI driver/plugin and hope that
> >> someone here may be able to give me some clues to help get this going.
> > We've found the FT232R to have unreliable timing in bitbang mode.
> > Depending on the receiver this can cause missed keypresses.  I would
> > recommend the FT230X series instead
> > http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_UMFT201_220_230XB.pdf
> > .  The FT232R is particularly unreliable with baud-rates other than
> > 65536.
> >
> > I've written a new driver called ftdix which takes advantage of the
> > reliable bitbang timing on the FT230X chips by adjusting the baud-rate
> > according to the carrier frequency.  This helps to improve reliability
> > and resource consumption.  I'll be proposing it in a patch once I've got
> > my previous 4 patches to the FTDI driver reviewed and upstream.  I'm
> > guessing the maintainer must be on holiday or busy at the moment.  You
> > can see it here:
> > https://github.com/stb-tester/lirc/commit/85a94b9ddd37ff4efbcae5edf54f0e9b499a2dbc
> >
> >
> Hi,
>
> I'm back again. Sorry for being unavailable for a too long time.
>
> Anyway, I would be happy to merge this patch. Two things would make it
> easier:
>
> - If you added a simple doc page in doc/plugindocs, use the existing
> ftdi.html as template. Preferably, also add a reference to ftdix in the
> ftdi page.
> - If you submitted it as a proper sourceforge merge request or filed a
> bug and attached the patch.

I've created a ticket for my 4 patch improvement series for the ftdi
driver.  I'll create another one for ftdix once these fixes go in:
https://sourceforge.net/p/lirc/tickets/182/

I hope that's correct.  I've not created a sourceforge ticket before,
I'm more used to the github PR model.

Thanks

Will

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Jasper
In reply to this post by Alec Leamas
Alec Leamas wrote
 Some questions:

- Have you installed lirc into standard locations i. e., something like
"make --prefix=/usr; make install"?
- What is the exact irsend command line you are running?
- Is there anything more in syslog?
- Is there anything more in syslog if you raise the loglevel to 'debug'?
- Are you using the master branch or the release-0_9_4 branch?
- If on master, does switching to release-0_9_4 make any difference?
I built as
./autogen
./configure --sysconfdir=/etc --prefix=/usr
make
sudo make install

lirc_options.conf is:
[lircd]
nodaemon        = False
driver          = girs
device          = /dev/ttyUSB1
output          = /run/lirc/lircd
pidfile         = /run/lirc/lircd.pid
plugindir       = /usr/lib/lirc/plugins
permission      = 666
allow-simulate  = No
repeat-max      = 600
#effective-user =
#listen         = [address:]port
#connect        = host[:port]
#debug          = 6
#uinput         = ...
#release        = ...
logfile         = /var/log/lircd.log

[lircmd]
uinput          = False
nodaemon        = False


The exact irsend command that causes problems is:
irsend SEND_ONCE --count=10 -d/run/lirc/lircd Pioneer_CU-VSX159 KEY_VOLUMEUP

I cannot use syslog normally as this is the 'broadcast message (http://lirc.10951.n7.nabble.com/GIRS-stray-trace-messages-td10765.html)' problem... but if I use a logfile at TRACE2:
http://pastebin.com/YDFQvhvq
with accompanying syslog:
Apr 27 21:34:36 nuliayuk irsend: lirc_command_run: Sending: SEND_ONCE Pioneer_CU-VSX159 KEY_VOLUMEUP 10
Apr 27 21:34:37 nuliayuk irsend: fill_string: timeout

Apr 27 21:34:53 nuliayuk irsend: message repeated 16 times: [ fill_string: timeout]
Apr 27 21:34:53 nuliayuk apcupsd[1627]: 000.0,000.0,233.2,27.40,50.00,07.8,22.0,000.0,000.0,233.2,100.0,1
Apr 27 21:34:54 nuliayuk irsend: fill_string: timeout
Apr 27 21:35:19 nuliayuk irsend: message repeated 25 times: [ fill_string: timeout]
Apr 27 21:35:20 nuliayuk irsend: fill_string: timeout
Apr 27 21:35:21 nuliayuk irsend: fill_string: timeout
Apr 27 21:35:22 nuliayuk irsend: fill_string: timeout
Apr 27 21:35:23 nuliayuk irsend: fill_string: timeout
Apr 27 21:35:24 nuliayuk irsend: fill_string: timeout

I am using the master branch... switching and rebuilding...
 Nope. No difference. Damn... back to master 8)
And with today’s updates in master it took more goes to get the fill_string timeout, but this could just be luck.

A note of comparison with homebrew serial: gers takes absolutely ages to send the command, near a second or so, whereas serial is instant.

Cheers,

Jasper
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Jasper
In reply to this post by lirc-5
lirc-5 wrote
I've created a ticket for my 4 patch improvement series for the ftdi
driver.  I'll create another one for ftdix once these fixes go in:
https://sourceforge.net/p/lirc/tickets/182/
Is it likely that these changes would have any baring on my problem? Should I retry and see.
If so can you please advise as to the correct --driver and --device etc that I need. I never got it right last time I tried.
Reply | Threaded
Open this post in threaded view
|

Re: FTDI IR Blaster not working

Bengt Martensson-2
In reply to this post by Jasper
On 04/27/16 11:01, Jasper wrote:
...
>
> A note of comparison with homebrew serial: gers takes absolutely ages to
> send the command, near a second or so, whereas serial is instant.

The first time it is "normal"; it is essentially inherent in the
Arduino, that resets when a serial connection is made. The workaround is
to connect ASAP, and then leave it.

If it happens more than the first time, please have a closer look in the
log.

Debugging LEDs are fairly practical for these kind of problems.

The serial driver is like MSDOS: there are so little in there, so
nothing can take time, therefore it is "fast"... ;-).

Greetz,

Bengt


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
12