lirc-list

Re: Trouble setting up an old Blaupunkt remote

[Bengt M. <bu...@be...>]

On 02/10/17 16:08, Thomas Orgis wrote:
> Hi,
>
> I purchased an USB irdroid transceiver, which is mostly an irtoy clone. I
> had to patch out the debugging LED code as that locks up the device
> (cdc-acm driver gets confused and I need to remove/reattach the USB
> device), see attached patch.

As previously reported on this list, the USB-irdroid is nothing but a 
stripped-down IrToy for a highter price, with ancient firmware, and no 
boot-loader to update it easily. See e.g. 
http://dangerousprototypes.com/forum/viewtopic.php?f=29&t=7401 .  As 
Alec hinted, the current Git contains a driver that identifies the 
firmware version (2.0 in irdroid, 2.2 is the official current) and 
avoids usage of the GPIO pins on old FW versions.

irrecord is a program from the last century. I suggest you use 
IrScrutinizer to capure the signals. It can generate lirc.conf files for 
you. It officially supports IrToy with FW 2.2, but I _think_ lower 
versions like 2.0 (i.e. irdroid) should work for capturing (not sending, 
but that is not the issue right now.)

> Now the device works with lirc-0.9.4d and
> I was able to record some remotes, complete with receiving and
> transmitting of button events.
>
> Now I got my hands on an old Blaupunkt remote, a nice chunky device
> with actual buttons made of hard plastic instead of rubber. The model
> number is 8668812302 and it looks like
>
> 	http://thomas.orgis.org/div/blaupunkt_8668812302.jpg

If you tell the name and version of the device to be controlled you/we 
might find the signals on the Internet (for example the Lirc remote data 
base...).

Greetz,

Bengt

Re: Trouble setting up an old Blaupunkt remote

[Thomas O. <tho...@or...>]

Am Fri, 10 Feb 2017 18:48:56 +0100
schrieb Alec Leamas <lea...@gm...>: 

> TBH, I don't completely understand the involved code... that said, have 
> you been using the same button every time you try to get the toggle bit 
> mask? Occasionally, using another button has worked for me.

Hm, no, it have been multiple attempts and I now tried again with one I
certainly did not use before. Nothing happens there.

What I would like to know if already that longer second line of dots in
the random button phase is normal.


Alrighty then,

Thomas

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

[Alec L. <lea...@gm...>]

On 10/02/17 18:43, Piotr Oniszczuk wrote:
> Hi,
> I’m developing small MythTV appliance (MiniMyth2) and decided to upgrade (highly stable) lirc 0.9.0 to 0.9.4b.
> MiniMyth2 heavily using irsend to control other multimedia equipment.
> After some adaptations I got all working with 0.9.4.
>
> Unfortunately I discovered annoying issue: for some remote types irblaster works very unreliably (1 from 10 sends is recognized by target equipment).
>
> Interesting is that LED diode on blaster blinks really slowly for sends when commands are unrecognized and normally fast (very similarly to 0.9.0) when command is correctly sent and recognized by target.
> This tells me that issue looks like sometimes irsend „plays” IR command with too „slow speed”.
> Also interesting is that I have this issue only with some remotes (i.e. Sharp TV).
> Other remotes (i.e. Sony amplituner) works like on 0.9.0 (100% reliably).

hm... Which driver/device are you using?

I also understand this as you are testing 0.9.0 and 0.9.4 on the same 
kernel, right? Which kernel, then?

Cheers!

--alec

Re: Trouble setting up an old Blaupunkt remote

[Alec L. <lea...@gm...>]

On 10/02/17 18:36, Thomas Orgis wrote:

> Ah, indeed, that one carries exactly the modification I hardcoded in
> the patch. That being said, the bad thing is that the behaviour of
> irrecord from master is unchanged. It has the long second dot line for
> the random button pressing, does not find any toggle mask, and records
> 0x0 as button codes.
>
> Ideas?

TBH, I don't completely understand the involved code... that said, have 
you been using the same button every time you try to get the toggle bit 
mask? Occasionally, using another button has worked for me.

Cheers!

--alec

lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

[Piotr O. <pio...@gm...>]

Hi,
I’m developing small MythTV appliance (MiniMyth2) and decided to upgrade (highly stable) lirc 0.9.0 to 0.9.4b.
MiniMyth2 heavily using irsend to control other multimedia equipment.   
After some adaptations I got all working with 0.9.4.

Unfortunately I discovered annoying issue: for some remote types irblaster works very unreliably (1 from 10 sends is recognized by target equipment).

Interesting is that LED diode on blaster blinks really slowly for sends when commands are unrecognized and normally fast (very similarly to 0.9.0) when command is correctly sent and recognized by target.
This tells me that issue looks like sometimes irsend „plays” IR command with too „slow speed”.
Also interesting is that I have this issue only with some remotes (i.e. Sharp TV).
Other remotes (i.e. Sony amplituner) works like on 0.9.0 (100% reliably).

lircd.conf for falling Sharp looks like this:

begin remote
  name          sharp_46x20e
  bits          15
  flags         SPACE_ENC
  eps           30
  aeps          100
  one           480  1680
  zero          480  560
  ptrail        480
  gap           10000
  repeat_bit    0
  frequency     38000

  begin codes
    power_tv    0x41A2
    power_tv_r  0x425D
    tv_vol+     0x40A2
    tv_vol+_r   0x435D
    tv_vol-     0x42A2
    tv_vol-_r   0x415D
    mute        0x43A3
    mute_r      0x405C
    1           0x4202
  end codes
end remote

I’m out of ideas how to track & resolve this issue. Now this effectively blocks me with going with 0.9.4 and forcing to stay on prehistoric (albeit very stable) 0.9.0.

All advices are very welcomed!
 

Re: Trouble setting up an old Blaupunkt remote

[Thomas O. <tho...@or...>]

Am Fri, 10 Feb 2017 16:19:42 +0100
schrieb Alec Leamas <lea...@gm...>: 

> Hm... before diving into details: the master branch contains an updated 
> irtoy driver with idroid support.

Ah, indeed, that one carries exactly the modification I hardcoded in
the patch. That being said, the bad thing is that the behaviour of
irrecord from master is unchanged. It has the long second dot line for
the random button pressing, does not find any toggle mask, and records
0x0 as button codes.

Ideas?


Alrighty then,

Thomas

Re: Trouble setting up an old Blaupunkt remote

[Alec L. <lea...@gm...>]

On 10/02/17 16:08, Thomas Orgis wrote:
> Hi,
>
> I purchased an USB irdroid transceiver, which is mostly an irtoy clone. I
> had to patch out the debugging LED code as that locks up the device
> (cdc-acm driver gets confused and I need to remove/reattach the USB
> device), see attached patch. Now the device works with lirc-0.9.4d and
> I was able to record some remotes, complete with receiving and
> transmitting of button events.


Hm... before diving into details: the master branch contains an updated 
irtoy driver with idroid support. Perhaps you should give it a try - I 
*think* you just could replace the irtoy.c file.

Cheers!

--alec

Trouble setting up an old Blaupunkt remote

[Thomas O. <tho...@or...>]

Hi,

I purchased an USB irdroid transceiver, which is mostly an irtoy clone. I
had to patch out the debugging LED code as that locks up the device
(cdc-acm driver gets confused and I need to remove/reattach the USB
device), see attached patch. Now the device works with lirc-0.9.4d and
I was able to record some remotes, complete with receiving and
transmitting of button events.

Now I got my hands on an old Blaupunkt remote, a nice chunky device
with actual buttons made of hard plastic instead of rubber. The model
number is 8668812302 and it looks like

	http://thomas.orgis.org/div/blaupunkt_8668812302.jpg

. It looks like the transceiver can see the signals just fine and I get
such output from a little test program that just dumps the bytes from
the irtoy sampling mode:

Mode response ("S01"):

53 30 31

Power button:

00 12 00 0d 00 1c 00 2f 00 1b 00 1f 00 1b 13 62 00 12 00 0f 00 1b 00 2f 00 1b 00 1f 00 1b ff ff 

Mute button:

00 12 00 3e 00 36 00 1f 00 1b 13 62 00 12 00 3e 00 36 00 1f 00 1b ff ff 


Now, when I fire up irrecord like

	irrecord -n -H irtoy -d /dev/ttyACM3  blauneu.conf

, it mostly looks fine, but results in no useful configuration. The
first funky thing is the overly long second row for the random initial
key presees.

----------8<--------------
irrecord -  application for recording IR-codes for usage with lirc
Copyright (C) 1998,1999 Christoph Bartelmus(li...@ba...)

This program will record the signals from your remote control
and create a config file for lircd.
[…]

Press RETURN now to start recording.
................................................................................
Got gap (109903 us)}

Please keep on pressing buttons like described above.
....................................................................................................................................................................................

Please enter the name for the next button (press <ENTER> to finish recording)
power

Now hold down button "power".

Please enter the name for the next button (press <ENTER> to finish recording)
mute 

Now hold down button "mute".

Please enter the name for the next button (press <ENTER> to finish recording)

Checking for toggle bit mask.
Please press an arbitrary button repeatedly as fast as possible.
Make sure you keep pressing the SAME button and that you DON'T HOLD
the button down!.
If you can't see any dots appear, wait a bit between button presses.

Press RETURN to continue.
Cannot find any toggle mask.

Successfully written config file blauneu.lircd.conf
-------->8----------------

So it fails to find a toggle mask but claims everything is fine … but
looking at the generated config file:

--------8<----------------
begin remote

  name  blauneu
  bits            0
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  one             0     0
  zero            0     0
  ptrail        575
  pre_data_bits   7
  pre_data       0x7F
  gap          109903
  toggle_bit_mask 0x0
  frequency    38000

      begin codes
          power                    0x0
          mute                     0x0
      end codes

end remote
-------->8----------------

Those button definitions do not look very useful.

Also, after the failed irrecord attempt, I got the driver confusion again …

[243460.101914] cdc_acm 3-2:1.0: failed to set dtr/rts

… maybe related to irrecord not resetting the device mode back from
sampling mode, which requires someone keeping the conversation going.
It would be nice to get the irtoy driver more stable with this device,
but my main issue seems to relate to this particular remote rigth now.
I might test with a serial port receiver some time to verify, but
currently I only got this one USB device to work with.

Does someone have an idea what is going wrong with the button detection
here? Where should one start to look? Judging from the raw irtoy output,
it looks like this old remote should still work.


Alrighty then,

Thomas

Re: lircrc file for Cyrus remote

[Alec L. <lea...@gm...>]

On 10/02/17 14:41, Zoltan Fekete wrote:
> Hi Alec,

Hi!

Please don't top-post, this will go into the archives

> Thanks for the kind response.
>
> I am running lirc on Raspberry pi, jessie release and it comes a
> seemingly patched version 0.9.0, which is old and there has been
> significant architectural changes. So upon receiving your mail, i
> decided to go for the latest stable version, downloaded 0.9.4d (plain
> vanilla version), installed it couple of times, but could not get it
> fully working. irw or irexec could not find the socket, though it was
> existing, permissions were ok, etc. (found some troubleshooting mails in
> the mailing list from you).

Basically, you should be able to run a modern lirc on jessie. The 
easiest path is to use the lirc-debian-src tarball, from which you can 
build .deb packages to install.

Another way is to update debian to the testing branch i. e., stretch 
which includes lirc-0.9.4c by default (this is no significant difference 
form the 0.9.4d release).

Anyway, you need to configure things, see [1].


Cheers!

--alec

[1] http://lirc.org/html/configuration-guide.html

Re: Lirc Remote Server

[Craig T. <ctr...@co...>]

> On Feb 8, 2017, at 6:14 AM, Alec Leamas <lea...@gm...> wrote:
> 
> On 07/02/17 14:31, Stefan Drees wrote:
> ...
>> FHEM stands for friendly homeautomation and energy measure. FHEM hast a
>> module to control an local lirc server and i hoped, i could use FHEM to
>> send an  command to the local lirc server and forward it to the other one.
>> Wasn't the --connect option (lircd) made for this?
> 
> No, not at all. The --connect/--listen options are used to connect 
> multiple lircd input sources i. e., to merge several remotes to a single 
> stream of button press events. IMHO, this is reasonably  described in 
> the lircd(8) manpage.
> 
> But, you can send commands to a lircd server anywhere on the network. 
> This is what irsend does given the --address option. The interface is a 
> simple, printable protocol described in lircd(8).
> 
> In your case, one possible path could be to patch your FHEM server to 
> use the --address option to irsend.
> 
> Another way could be to set up a tunnel between the local UNIX socket 
> and the remote lircd server using e. g. ncat(1), hiding the fact that 
> the lircd server is a remote one for FHEM.
> 
> I can see a irsend(1) shortcoming here: there is no way to specify a 
> remote server used by default in the same way as for a local socket 
> (this is for modern LIRC, not 0.9.0).

Some information about FHEM and Lirc is here:

http://fhem.de/commandref.html#LIRC

Apparently it uses a Perl module to interface wtih Lirc.  Information about that, here:

http://search.cpan.org/~mgrimes/Lirc-Client-2.02/lib/Lirc/Client.pm

Craig

Re: Lirc Remote Server

[Alec L. <lea...@gm...>]

On 08/02/17 13:00, Stefan Drees wrote:

> Thanks for the detailed description, i try to patch FHEM to use the
> irsend address option.

That is, if it's using irsend.  There are other possibilities, for sure...


Cheers!

--alec

Re: Lirc Remote Server

[Stefan D. <st...@ar...>]

Am 8. Februar 2017 12:19:19 nachm. schrieb Alec Leamas <lea...@gm...>:

>
> On 07/02/17 14:31, Stefan Drees wrote:
>> Hi,
>
> Hi
>
> First: please don't top-post, it makes the archive hard to read.
>
>> FHEM stands for friendly homeautomation and energy measure. FHEM hast a
>> module to control an local lirc server and i hoped, i could use FHEM to
>> send an  command to the local lirc server and forward it to the other one.
>> Wasn't the --connect option (lircd) made for this?
>
> No, not at all. The --connect/--listen options are used to connect
> multiple lircd input sources i. e., to merge several remotes to a single
> stream of button press events. IMHO, this is reasonably  described in
> the lircd(8) manpage.
>
> But, you can send commands to a lircd server anywhere on the network.
> This is what irsend does given the --address option. The interface is a
> simple, printable protocol described in lircd(8).
>
> In your case, one possible path could be to patch your FHEM server to
> use the --address option to irsend.
>
> Another way could be to set up a tunnel between the local UNIX socket
> and the remote lircd server using e. g. ncat(1), hiding the fact that
> the lircd server is a remote one for FHEM.
>
> I can see a irsend(1) shortcoming here: there is no way to specify a
> remote server used by default in the same way as for a local socket
> (this is for modern LIRC, not 0.9.0).
>
>
> Cheers!
>
> --alec
>
>
>
>

Hi,
Sorry, my mistake.
Thanks for the detailed description, i try to patch FHEM to use the irsend 
address option.

Thanks.

Regards
Stefan

Re: Lirc Remote Server

[Alec L. <lea...@gm...>]

On 07/02/17 14:31, Stefan Drees wrote:
> Hi,

Hi

First: please don't top-post, it makes the archive hard to read.

> FHEM stands for friendly homeautomation and energy measure. FHEM hast a
> module to control an local lirc server and i hoped, i could use FHEM to
> send an  command to the local lirc server and forward it to the other one.
> Wasn't the --connect option (lircd) made for this?

No, not at all. The --connect/--listen options are used to connect 
multiple lircd input sources i. e., to merge several remotes to a single 
stream of button press events. IMHO, this is reasonably  described in 
the lircd(8) manpage.

But, you can send commands to a lircd server anywhere on the network. 
This is what irsend does given the --address option. The interface is a 
simple, printable protocol described in lircd(8).

In your case, one possible path could be to patch your FHEM server to 
use the --address option to irsend.

Another way could be to set up a tunnel between the local UNIX socket 
and the remote lircd server using e. g. ncat(1), hiding the fact that 
the lircd server is a remote one for FHEM.

I can see a irsend(1) shortcoming here: there is no way to specify a 
remote server used by default in the same way as for a local socket 
(this is for modern LIRC, not 0.9.0).


Cheers!

--alec

Re: Lirc Remote Server

[Stefan D. <st...@ar...>]

Hi,
FHEM stands for friendly homeautomation and energy measure. FHEM hast a 
module to control an local lirc server and i hoped, i could use FHEM to 
send an  command to the local lirc server and forward it to the other one. 
Wasn't the --connect option (lircd) made for this?

Regards
Stefan


Am 7. Februar 2017 1:06:24 nachm. schrieb 
lir...@li...:

> Send LIRC-list mailing list submissions to
> 	lir...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/lirc-list
> or, via email, send a message with subject or body 'help' to
> 	lir...@li...
>
> You can reach the person managing the list at
> 	lir...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of LIRC-list digest..."
>
>
> Today's Topics:
>
>    1. Lirc Remote Server (Stefan Drees)
>    2. Wrong tarball name for 0.9.4d release (Thomas Orgis)
>    3. Re: Lirc Remote Server (Alec Leamas)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 06 Feb 2017 21:03:50 +0100
> From: Stefan Drees <st...@ar...>
> Subject: Lirc Remote Server
> To: <lir...@li...>
> Message-ID:
> 	<15a...@ar...>
> Content-Type: text/plain; format=flowed; charset="us-ascii"
>
> Hello,
> hope someone can help me.
> I have one lirc Server in my living room and want to control it from
> another lirc server via fhem.
> I configured the lirc Server in the living room with --listen but how do I
> need to configure the lirc server on my fhem server? I tried with
> --connect=server:8765 but if I try irsend it says: hardware does not
> support sending.
>
> Hope someone can help me or give mehr an example configuration.
>
> Thanks
>
> Best regards
> Stefan
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 4 Feb 2017 17:09:06 +0100
> From: Thomas Orgis <tho...@or...>
> Subject: Wrong tarball name for 0.9.4d release
> To: lir...@li...
> Message-ID: <20170204170906.6c3068a6@sturbolzen>
> Content-Type: text/plain; charset="utf-8"
>
> Hi LIRC folks,
>
> inside
>
> 	https://sourceforge.net/projects/lirc/files/LIRC/0.9.4d/
>
> I see
>
> 	https://sourceforge.net/projects/lirc/files/LIRC/0.9.4d/lirc-0.9.4c.tar.bz2/download
>
> instead of
>
> 	https://sourceforge.net/projects/lirc/files/LIRC/0.9.4d/lirc-0.9.4d.tar.bz2/download
>
> I am resorting to the tar.gz ? but I presume you just got the name of
> the file wrong, as it seems to differ from the actual
> lirc-0.9.4c.tar.bz2. You might want to fix the name.
>
>
> Alrighty then,
>
> Thomas
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 801 bytes
> Desc: Digitale Signatur von OpenPGP
>
> ------------------------------
>
> Message: 3
> Date: Tue, 7 Feb 2017 09:31:56 +0100
> From: Alec Leamas <lea...@gm...>
> Subject: Re: Lirc Remote Server
> To: lir...@li...
> Message-ID: <2e4...@gm...>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
>
> On 06/02/17 21:03, Stefan Drees wrote:
>> Hello,
>> hope someone can help me.
>> I have one lirc Server in my living room and want to control it from
>> another lirc server via fhem.
>
> fhem? What's that?
>
>> I configured the lirc Server in the living room with --listen but how do I
>> need to configure the lirc server on my fhem server? I tried with
>> --connect=server:8765 but if I try irsend it says: hardware does not
>> support sending.
>
> If I understand your situation correctly, you don't need any --listen
> option in this case. Just use the --address option to irsend to make it
> connect to the remote living room server.  This also means that there
> probably should be just one server, the one on in the living room.
>
>
> Cheers!
>
> --alec
>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
> End of LIRC-list Digest, Vol 107, Issue 2
> *****************************************

Re: Lirc Remote Server

[Alec L. <lea...@gm...>]

On 06/02/17 21:03, Stefan Drees wrote:
> Hello,
> hope someone can help me.
> I have one lirc Server in my living room and want to control it from
> another lirc server via fhem.

fhem? What's that?

> I configured the lirc Server in the living room with --listen but how do I
> need to configure the lirc server on my fhem server? I tried with
> --connect=server:8765 but if I try irsend it says: hardware does not
> support sending.

If I understand your situation correctly, you don't need any --listen 
option in this case. Just use the --address option to irsend to make it 
connect to the remote living room server.  This also means that there 
probably should be just one server, the one on in the living room.


Cheers!

--alec

Lirc Remote Server

[Stefan D. <st...@ar...>]

Hello,
hope someone can help me.
I have one lirc Server in my living room and want to control it from 
another lirc server via fhem.
I configured the lirc Server in the living room with --listen but how do I 
need to configure the lirc server on my fhem server? I tried with 
--connect=server:8765 but if I try irsend it says: hardware does not 
support sending.

Hope someone can help me or give mehr an example configuration.

Thanks

Best regards
Stefan

Wrong tarball name for 0.9.4d release

[Thomas O. <tho...@or...>]

Hi LIRC folks,

inside

	https://sourceforge.net/projects/lirc/files/LIRC/0.9.4d/

I see

	https://sourceforge.net/projects/lirc/files/LIRC/0.9.4d/lirc-0.9.4c.tar.bz2/download

instead of

	https://sourceforge.net/projects/lirc/files/LIRC/0.9.4d/lirc-0.9.4d.tar.bz2/download

I am resorting to the tar.gz … but I presume you just got the name of
the file wrong, as it seems to differ from the actual
lirc-0.9.4c.tar.bz2. You might want to fix the name.


Alrighty then,

Thomas

Re: Aw: LIRC-list Digest, Vol 106, Issue 11

[Alec L. <lea...@gm...>]

On 03/02/17 18:39, Sof...@qu... wrote:

> What is the opinion of this lirc group
I'm certainly not a group..

> - is lirc_rpi about to be retired?

As I understand it, it cannot be retired from the kernel since it has 
never been part of it. Looks like it being added by  some downstream 
users e. g., raspbian.

What raspbian intends to do you must talk to them about...

> - would a driver from the Linus' linux kernel make it into raspbian (else useless)?

Well, if you made a proper driver based on the RC framework as other 
LIRC drivers AND it was accepted by the upstream kernel at kernel.org it 
will eventually trickle down to raspbian.

The flow is that debian first updates it's kernel from kernel.org, than 
raspbian uses the new debian releas. Neither of these projects are 
fast-moving, so it will take time.

Since your primary focus seems to be raspbian, it might be better to 
talk those folks.


Cheers!

--alec

Aw: LIRC-list Digest, Vol 106, Issue 11

[<Sof...@qu...>]

Dear colleagues

A month ago or so I patched lirc_rpi to support hardware pulse-wave modulation for the carrier frequency on Raspberry Pi. Members of this list kindly advised me, whom to contact to get the patch considered into the kernel. After a few mail exchanges, I was informed that lirc_rpi is not officially supported by the maintainer of "Linus' linux kernel" as they called it. Instead, I should write a driver based on RC core (https://github.com/torvalds/linux/tree/master/drivers/media/rc).

What is the opinion of this lirc group
- is lirc_rpi about to be retired?
- would a driver from the Linus' linux kernel make it into raspbian (else useless)?

Thank you for advice

A

Re: Testing Tira 2.1

[Bengt M. <bu...@be...>]

On 01/25/17 15:04, Craig Treleaven wrote:
>> On Jan 25, 2017, at 4:10 AM, Bengt Martensson <bu...@be...> wrote:
...

>>>> So it should work, using one of these devices.
>>>>
>>> Oh, but if I only _had_ those devices!  I don’t know why but I have nothing like that.
>>
>> Then THAT, and nothing else is the problem: The OS does not recognize
>> the device. I think I have even adjusted some EEPROM parameter on the
>> Mac to have them recognized, but I cannot remember... It may have
>> something to do with "signed drivers" or such. Search the Internet. This
>> may be a start:
>> http://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html
>>
>> Be sure to report the solution when you have found it.
>
> Um, the instructions on that page are pretty extreme:  unloading Apple kernal extensions (kext, aka
> “drivers”), changing NVRAM settings to boot into kext development mode, etc.  Installing binaries
> that came from Chinese and Russian sources. ...

I have boot-args kext-dev-mode=1 in nvram, possibly that makes the 
difference. Since with Linux the device shows up for lsusb as FTDI, you 
may try to install the FTDI Mac drivers, or follow FTDI's instructions, see
http://www.ftdichip.com/Support/Documents/InstallGuides/Mac_OS_X_Installation_Guide.pdf


>
> Anyway, on your Mac, Tira mounts a /dev/tty.usbserial-HE00001 device and mine does not.  Either
> your software is different…or your Tira is not the same.
>
> The ioreg command can give details of certain objects.  Use the the full name of the device ala
> “-n Tira-2@fd120000”.
>

Mine is not that different:

+-o Root  <class IORegistryEntry, id 0x100000100, retain 13>
   +-o Root Hub Simulation Simulation@04000000  <class 
AppleUSBRootHubDevice, id 0x10000025f, registered, matched, active, busy 
0 (3 ms), retain 7>
   | +-o IR Receiver@04500000  <class AppleUSBDevice, id 0x100000260, 
registered, matched, active, busy 0 (70 ms), retain 14>
   +-o Root Hub Simulation Simulation@06000000  <class 
AppleUSBRootHubDevice, id 0x10000026e, registered, matched, active, busy 
0 (3 ms), retain 8>
     +-o BRCM2046 Hub@06100000  <class AppleUSBDevice, id 0x10000026f, 
registered, matched, active, busy 0 (1 ms), retain 12>
     | +-o Bluetooth USB Host Controller@06110000  <class 
AppleUSBDevice, id 0x100000283, registered, matched, active, busy 0 (2 
ms), retain 17>
     +-o Tira-2@06400000  <class AppleUSBDevice, id 0x10000055c, 
registered, matched, active, busy 0 (4601 ms), retain 14>
         {
           "sessionID" = 8461543888030
           "iManufacturer" = 1
           "bNumConfigurations" = 1
           "idProduct" = 64120
           "bcdDevice" = 1024
           "Bus Power Available" = 500
           "USB Address" = 3
           "bMaxPacketSize0" = 8
           "iProduct" = 2
           "iSerialNumber" = 3
           "bDeviceClass" = 0
           "Built-In" = No
           "locationID" = 104857600
           "bDeviceSubClass" = 0
           "bcdUSB" = 272
           "USB Product Name" = "Tira-2"
           "PortNum" = 4
           "non-removable" = "no"
           "IOCFPlugInTypes" = 
{"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
           "bDeviceProtocol" = 0
           "IOUserClientClass" = "IOUSBDeviceUserClientV2"
           "IOPowerManagement" = 
{"ChildrenPowerState"=4,"DevicePowerState"=0,"CurrentPowerState"=4,"CapabilityFlags"=32768,"MaxPowerState"=4,"DriverPowerState"=4}
           "Device Speed" = 1
           "USB Vendor Name" = "Home Electronics"
           "idVendor" = 1027
           "IOGeneralInterest" = "IOCommand is not serializable"
           "USB Serial Number" = "HE000001"
           "IOClassNameOverride" = "IOUSBDevice"
         }


If this does not help, I suggest you seek help from Mac experts.

Greetz,

Bengt

Re: Testing Tira 2.1

[Craig T. <ctr...@co...>]

> On Jan 25, 2017, at 4:10 AM, Bengt Martensson <bu...@be...> wrote:
> 
> On 01/24/17 23:02, Craig Treleaven wrote:
>>> On Jan 24, 2017, at 2:22 PM, Bengt Martensson <bu...@be...> wrote:
>>> 
>>> On 01/24/17 19:24, Craig Treleaven wrote:
>>>>> On Jan 24, 2017, at 7:32 AM, Alec Leamas <lea...@gm...> wrote:
>>>>> 
>>>>> On 24/01/17 13:07, Craig Treleaven wrote:
>>>>>> The good folks at Home Electronics have lent me a Tira 2.1 IR receiver to test with Lirc under Mac OS X.
>>> ...
>>>>> That said, looking at the source it seems that the tira device should be
>>>>> visible as /dev/ttyUSB?, typically /dev/ttyUSB0 which then is the device
>>>>> to use.
>>> 
>>> Correct; the TIRA does serial-over-USB emulation, like FTDI, and many of
>>> our favorite devices, like Arduino, USB-uirt, CommandFusion, IrToy, but
>>> unlike commandIR, Iguana,.. As Alec says, with Linux it shows up as
>>> /dev/ttyUSBn (n = 0,1,2,...). On my Mac (Mac Mini "early 2009", MacOS
>>> 10.11.6) it shows up as /dev/tty.usbserial-HE00001 as well as
>>> /dev/cu.usbserial-HE00001. (These two differs in how they treat some
>>> modem control lines; on Solaris it was /dev/tty* for dial-in and cu for
>>> dial-out, IIRC.)
>>> 
>>> So it should work, using one of these devices.
>>> 
>> Oh, but if I only _had_ those devices!  I don’t know why but I have nothing like that.
> 
> Then THAT, and nothing else is the problem: The OS does not recognize 
> the device. I think I have even adjusted some EEPROM parameter on the 
> Mac to have them recognized, but I cannot remember... It may have 
> something to do with "signed drivers" or such. Search the Internet. This 
> may be a start:
> http://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html
> 
> Be sure to report the solution when you have found it.

Um, the instructions on that page are pretty extreme:  unloading Apple kernal extensions (kext, aka
“drivers”), changing NVRAM settings to boot into kext development mode, etc.  Installing binaries
that came from Chinese and Russian sources. ...

Anyway, on your Mac, Tira mounts a /dev/tty.usbserial-HE00001 device and mine does not.  Either 
your software is different…or your Tira is not the same.

The ioreg command can give details of certain objects.  Use the the full name of the device ala 
“-n Tira-2@fd120000”. 

Details from my setup are:

CT-MBP11:lirc craigtreleaven$ ioreg -w0 -p IOUSB -nTira-2@fd120000
+-o Root  <class IORegistryEntry, id 0x100000100, retain 10>
  +-o EHCI Root Hub Simulation@1D,7  <class IOUSBRootHubDevice, id 0x100000227, registered, matched, active, busy 0 (15 ms), retain 13>
  | +-o HubDevice@fd100000  <class IOUSBHubDevice, id 0x100000290, registered, matched, active, busy 0 (6 ms), retain 15>
  |   +-o IR Receiver@fd110000  <class IOUSBDevice, id 0x1000002a0, registered, matched, active, busy 0 (51 ms), retain 12>
  |   +-o Tira-2@fd120000  <class IOUSBDevice, id 0x100000a58, registered, matched, active, busy 0 (695 ms), retain 11>
  |       {
  |         "sessionID" = 18681502702885
  |         "idProduct" = 64120
  |         "bNumConfigurations" = 1
  |         "iManufacturer" = 1
  |         "bcdDevice" = 1536
  |         "Bus Power Available" = 250
  |         "bMaxPacketSize0" = 8
  |         "USB Product Name" = "Tira-2"
  |         "iProduct" = 2
  |         "iSerialNumber" = 0
  |         "USB Address" = 4
  |         "IOUserClientClass" = "IOUSBDeviceUserClientV2"
  |         "bDeviceSubClass" = 0
  |         "bDeviceClass" = 0
  |         "bcdUSB" = 512
  |         "locationID" = 18446744073660399616
  |         "PortNum" = 2
  |         "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
  |         "bDeviceProtocol" = 0
  |         "USB Vendor Name" = "Home Electronics"
  |         "Device Speed" = 1
  |         "idVendor" = 1027
  |         "Requested Power" = 55
  |         "IOGeneralInterest" = "IOCommand is not serializable"
  |         "Low Power Displayed" = No
  |       }
  |       
  +-o EHCI Root Hub Simulation@1A,7  <class IOUSBRootHubDevice, id 0x10000022e, registered, matched, active, busy 0 (13 ms), retain 15>
    +-o HubDevice@fa100000  <class IOUSBHubDevice, id 0x10000028f, registered, matched, active, busy 0 (5 ms), retain 17>
    | +-o BRCM2070 Hub@fa110000  <class IOUSBHubDevice, id 0x1000002a6, registered, matched, active, busy 0 (4 ms), retain 13>
    | | +-o Bluetooth USB Host Controller@fa113000  <class IOUSBDevice, id 0x1000002bc, registered, matched, active, busy 0 (60 ms), retain 14>
    | +-o Apple Internal Keyboard / Trackpad@fa120000  <class IOUSBDevice, id 0x1000002aa, registered, matched, active, busy 0 (508 ms), retain 16>
    | +-o USB-PS/2 Optical Mouse@fa130000  <class IOUSBDevice, id 0x1000002b9, registered, matched, active, busy 0 (98 ms), retain 12>
    +-o FaceTime HD Camera (Built-in)@fa200000  <class IOUSBDevice, id 0x10000029a, registered, matched, active, busy 0 (74 ms), retain 15>


Notice the “IOCFPlugInTypes" — I believe this means that the standard Apple USB kext has 
got (exclusive?) access to the device.

Bengt, if you run a similar command, what kext is handling your device?  Is your’s a “Tira-2”?  
Any indication that I’ve got a different hardware rev?

Thanks for the help,

Craig

Re: Device enumerations

[Alec L. <lea...@gm...>]

On 25/01/17 09:56, Bengt Martensson wrote:
> [Changed subject; this is not Tira anymore]
>
> On 01/24/17 20:36, Alec Leamas wrote:
>>
>>
>> On 24/01/17 19:24, Craig Treleaven wrote:

>
> I do not claim that I understand the low-level stuff as Alec does, but
> here is what I envision (at least for serial-over-USB devices):
> Something that delivers a map of human readable descriptions (Vendor,
> serialID, etc) to device names. This should both be available as a
> command line program, delivering an output like
>
> IrToy -> /dev/ttyACM0
> Arduino Uno, serial 12345 -> /dev/ttyACM1

The command is mode2 --driver=... --list-devices. The output is a single 
line for each device. First word is the 'device', acceptable as argument 
to --device for actual driver. The rest is basically free format info, 
for use in UI. If present, a string like [1234:5678] is the usb 
vendorId:productId. With a linux kernel the info comes from udev in most 
cases, even if the enumeration might be based on other sources.

The code is in lib/drv_enum.c and drv.enum.h. There are routines to 
enumerate based on glob patterns and libudev enumeration.

Note that in general, devices not always have a name. On linux, the /dev 
link is the unique identifier required. MacOS perhaps blurs this picture 
(?), but it's possible to adapt as I described.

> Hard do image that something like this does not exist already...???

Indeed. But in master almost all drivers now support it

A *big* exception is drivers using serial connections /dev/tty*. These 
are as of now handled by lirc-setuo, and it might be the only reasonable 
way since it involves  modprobe settings for irq etc.


Cheers!

--alec

PS Next version 0.9.5 is dead. Long live 0.10.0!  DS

Re: Testing Tira 2.1

[Bengt M. <bu...@be...>]

On 01/24/17 23:02, Craig Treleaven wrote:
>> On Jan 24, 2017, at 2:22 PM, Bengt Martensson <bu...@be...> wrote:
>>
>> On 01/24/17 19:24, Craig Treleaven wrote:
>>>> On Jan 24, 2017, at 7:32 AM, Alec Leamas <lea...@gm...> wrote:
>>>>
>>>> On 24/01/17 13:07, Craig Treleaven wrote:
>>>>> The good folks at Home Electronics have lent me a Tira 2.1 IR receiver to test with Lirc under Mac OS X.
>> ...
>>>> That said, looking at the source it seems that the tira device should be
>>>> visible as /dev/ttyUSB?, typically /dev/ttyUSB0 which then is the device
>>>> to use.
>>
>> Correct; the TIRA does serial-over-USB emulation, like FTDI, and many of
>> our favorite devices, like Arduino, USB-uirt, CommandFusion, IrToy, but
>> unlike commandIR, Iguana,.. As Alec says, with Linux it shows up as
>> /dev/ttyUSBn (n = 0,1,2,...). On my Mac (Mac Mini "early 2009", MacOS
>> 10.11.6) it shows up as /dev/tty.usbserial-HE00001 as well as
>> /dev/cu.usbserial-HE00001. (These two differs in how they treat some
>> modem control lines; on Solaris it was /dev/tty* for dial-in and cu for
>> dial-out, IIRC.)
>>
>> So it should work, using one of these devices.
>>
> Oh, but if I only _had_ those devices!  I don’t know why but I have nothing like that.

Then THAT, and nothing else is the problem: The OS does not recognize 
the device. I think I have even adjusted some EEPROM parameter on the 
Mac to have them recognized, but I cannot remember... It may have 
something to do with "signed drivers" or such. Search the Internet. This 
may be a start:
http://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html

Be sure to report the solution when you have found it.

 > I’ve seen mention of Girs a couple of times.  If you have a Mac, have 
you not tested Lirc there?

It should "just work", if the device is recognized.

Greetz,

Bengt

Device enumerations

[Bengt M. <bu...@be...>]

[Changed subject; this is not Tira anymore]

On 01/24/17 20:36, Alec Leamas wrote:
>
>
> On 24/01/17 19:24, Craig Treleaven wrote:
>
>>
>> It seems that plugins/osx_usbraw.c uses a very different approach to accessing the Sony IR receiver.  It may be that this just isn’t going to work.
>
> Yes... With the new enumerating support in place it's "probably"
> straight-forward to make a patch avoiding the linux devices completely.
> The key thing is that it seems like libusb (both 0.12 and 1.0) exists on
> MacOS as it also does on linux.

I do not claim that I understand the low-level stuff as Alec does, but 
here is what I envision (at least for serial-over-USB devices): 
Something that delivers a map of human readable descriptions (Vendor, 
serialID, etc) to device names. This should both be available as a 
command line program, delivering an output like

IrToy -> /dev/ttyACM0
Arduino Uno, serial 12345 -> /dev/ttyACM1

callable both from C and other languages (Python, Java (delivering a 
Map<String,File>), ...)

lircd can then just regexp-match the user's device against the keys in 
this list. The plugins just contains a regexp that is used if the user's 
device is missing. Thus the enumeration code can be taken out of the 
plugins, at least for serial-over-USB devices.

I can surely use it in IrScrutinizer too.

Hard do image that something like this does not exist already...???

Greetz,

Bengt

Re: Testing Tira 2.1

[Craig T. <ctr...@co...>]

> On Jan 24, 2017, at 2:22 PM, Bengt Martensson <bu...@be...> wrote:
> 
> On 01/24/17 19:24, Craig Treleaven wrote:
>>> On Jan 24, 2017, at 7:32 AM, Alec Leamas <lea...@gm...> wrote:
>>> 
>>> On 24/01/17 13:07, Craig Treleaven wrote:
>>>> The good folks at Home Electronics have lent me a Tira 2.1 IR receiver to test with Lirc under Mac OS X.
> ...
>>> That said, looking at the source it seems that the tira device should be
>>> visible as /dev/ttyUSB?, typically /dev/ttyUSB0 which then is the device
>>> to use.
> 
> Correct; the TIRA does serial-over-USB emulation, like FTDI, and many of 
> our favorite devices, like Arduino, USB-uirt, CommandFusion, IrToy, but 
> unlike commandIR, Iguana,.. As Alec says, with Linux it shows up as 
> /dev/ttyUSBn (n = 0,1,2,...). On my Mac (Mac Mini "early 2009", MacOS 
> 10.11.6) it shows up as /dev/tty.usbserial-HE00001 as well as 
> /dev/cu.usbserial-HE00001. (These two differs in how they treat some 
> modem control lines; on Solaris it was /dev/tty* for dial-in and cu for 
> dial-out, IIRC.)
> 
> So it should work, using one of these devices.
> 
Oh, but if I only _had_ those devices!  I don’t know why but I have nothing like that.

$ sudo ls -al /dev/tty.*
crw-rw-rw-  1 root  wheel   17,   0 23 Jan 20:03 /dev/tty.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel   17,   2 23 Jan 20:03 /dev/tty.Bluetooth-Modem

I’m on a MacBook Pro (2011) running 10.10.5.  I can’t imagine that this was
something added in 10.11.  

I will try connecting the Tira to my other Macs.

> BTW, it appears as your goal is to get as many "things" as possible to 
> work with MacOS. Have you tried my baby: the Girs driver and (e.g.) an 
> Arduino like this: http://www.harctoolbox.org/arduino_nano.html ? It 
> "should" work.

My main interest is MythTV on Mac.  I created a standalone all-in-one installer
that makes it easy to run a complete Myth system on OS X.  However, remote
control remains a problem for some people.  The ‘gum stick’ remote works (with certain
Mac models but isn’t very full-featured.  I’ve used Lirc for 8 or 9 years with a 
SiliconDust HDHomerun forwarding IR over udp.  Works great for me but new 
models don’t have that feature.

In fact, Lirc was my introduction to the MacPorts project.  The fellow that was
maintaining our port at that time worked with me to get udp functioning.  I think the
IguanaIR was the only hardware known to work at that time.  Later, I began contributing
to MacPorts and eventually took over as maintainer for the Lirc port.

I was hoping that if the Tira ‘just worked’, it would bode well for some of the other 
USB devices.  Thanks for your explanation about serial-over-USB; that helps me
understand a bit better.

I’ve seen mention of Girs a couple of times.  If you have a Mac, have you not tested Lirc
there?  It is easy enough with MacPorts but that really doesn’t give you a good environment
for Lirc development.  MacPorts is oriented towards reliable, repeatable builds.

Craig