Using Infra Red via IOIO-Board

[Siggi]

Hi to all,

Currently, I try to use the IOIO-Board among other things as an InfraRed (IR) transmitter. Perhaps it sounds easy, but I got into the following problems and would be happy, if someone could share his experience and knowledge!

I am using a development board (right now, there are two different boards in use - the BeagleBoard xM and the pico-SAM9G45 board) with Android Gingerbread (v. 2.3.4). Communication between the IOIO-Board and the development board is done via ADB. I connected an IR-LED to the IOIO-Board to be able to send IR commands to other devices. Due to the IR protocol, I must meet some timing constraints: The IR commands have to be sent out with 38000 Hz, thus leads to a period of about 26 micro-seconds and to a pulse-width of about 13 micro-seconds.

Here some information about the used IR protocol (Raw oscillated code): http://www.hifi-remote.com/infrared/prontoirformats.pdf

My problem is, that I am not able to send out all bits of the command in time!

At first, I tried to "bit-bang" the IR code, by accessing the IR-LED pin directlty (notice, that you will need a frequency of 76000Hz, if you bit-bang the commands):
The first problem with this approach was, that it was not possible for me to write fast enough (13 micro-seconds pulse-width) to the used IR-LED pin, since I got "ConnectionLostExceptions". I meassured the time needed to be past between direct writes to the particular pin and it turned out that it should be at least 20-30 micro-seconds past to avoid the mentioned exceptions (this is too much, since I need only 13 micro-seconds to be past).
The second problem is that even if it should be possible to write to the IR-LED pin directly within the needed time, sometimes the current process will be scheduled and the IR communications will be broken for at least 10 milli-seconds, since I am using an operating system.

Next I had to find out, whether it is possible to use some serial interfaces for accessing the IR-LED pin within the timing constraints. I thought of UART and SPI (IIC and SMBus were not considered, since they use fixed, and to fast frequencies). Of course, it turned out that UART uses Start- and Stop-Bits essential for the UART protocol, so it was excluded. SPI was a pretty good candidate for my project, but since it uses only fixed frequency-rates I could not adjust it for my needs (since it would be also a kind of bit-banging I need a frequency of 76000 Hz).

Right now, I am looking for IR-Transmitter IC's and wondering, whether it is really not possible to avoid this step...

PS: this is the current IR-Transmitter IC I am considering to order: http://www.rentron.com/Files/TX-IR.pdf
PPS: funny, that it is not a problem at all to realize a IR transmitter on a Arduino, but such a big thing for me to do it using a much faster board ;)

[Ytai Ben-Tsvi]

IOIO is not very well suited for bit-banging as the latency and jitter will kill you, and possibly the excessive bandwidth needed to send a command end-to-end over thick protocol stacks.

The preferred solution in this case is to implement the low-level bits of the protocol on the IOIO side and send high-level commands from the Android side. This will of course require you to customize the firmware, which is a different level of complexity than being a standard user.

Having said that, IR remote support is on the wish list. I'll probably get around to implementing it, if no one else does, within a few months.

Ytai

[Siggi]

We finally managed to transceive IR commands via IOIO!
Thanks for your advice to extend the Firmware on the IOIO-Board. It was pretty helpful, since it works now ;)

With best regards,
Siggi

[ZHANG Yan]

Is there a possibilty to integrate IR officially in IOIO?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/i_vixBsiH7EJ.

To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.

[Ytai Ben-Tsvi]

Great! Siggi, can you send me a Git patch? I'll try integrate it into one of the next releases.

[Siggi]

Hi Ytai,

Sure, we will refactor the code on monday and send you a git-patch :)

Cheers,
Siggi

[Siggi]

Hi guys,

here is a small demonstration of the extended IOIO firmware including IR transmission posted on youtube, enjoy!

http://www.youtube.com/watch?v=pNZb84uA81c

PS: thanks to ytai

[Ytai Ben-Tsvi]

SO COOOOOOL!!!

Send this to hackaday! And thanks for sharing your code too.

One comment: you really should connect a resistor (100 ohm or more) in series with the LED or else you may damage your IOIO pin pretty soon. It was hard to see on the video, but it looked like the LED is connected directly from the pin to ground.

--

You received this message because you are subscribed to the Google Groups "ioio-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/WXOlhca2XFgJ.

[Siggi]

will do, thanks for the advice!
nice, that you liked the video :)

Cheers

[JHE]

Hello, Siggi. I am trying to do the same project using IOIO board. Can you send me the firmware code you have done as for my reference? I bumped into the same problem you described in the post. I would really appreciate your help. 

Thank you ;)

[abner.ayala]

Just like JHE, I am also very interested in this, if I am provided with some open source, or it is updated on the IOIO firmware.

Siggi any word from Ytai on when this might be available?
This seems to significantly simplify IR applications?
Do you create APIs or libraries that one can eventually call and already generate the desire infrared output, or is your application hard-coded, and others will have create there own IR signals?

Either way great job, and hope to know some more about this on the upcoming future.

[Markus Lanthaler]

Hi all,

 

I was working with Siggi on the same project. I refactored the code a bit and ported it to the newest firmware version [1]. I also just opened a pull request [2]. You can send any arbitrary IR code (there's still a small bug that I couldn't track down so I had to hard-code the carrier frequency). Hope this helps.

 

Feel free to fork the PR and improve it.. there are still some things that could be improved.

 

[1] https://github.com/lanthaler/ioio/

[2] https://github.com/ytai/ioio/pull/25

 

 

Cheers,

Markus

 

 

--
Markus Lanthaler
@markuslanthaler

[Jeff Eberl]

This is for RC-5. Or a more generic version perhaps?

--

You received this message because you are subscribed to the Google Groups "ioio-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/VgBekCmiEbEJ.

[Jeff Eberl]

Oops. I should read all my email before responding.

I'm very excited though. Probably too much. I want to help, and I will definitely look at this in the next week or two.

[Markus Lanthaler]

It’s more generic.. It supports every kind of infrared code where the duty cycle doesn’t matter, i.e., it is 50%. So you can use it without problems for RC-5.

[Markus Lanthaler]

> Oops. I should read all my email before responding.

:-)

> I'm very excited though. Probably too much. I want to
>help, and I will definitely look at this in the next week or two.

Great! Please note that this is just the part that sends the data. The
"learning receiver" is a bit more complex. At least if you wanna support
more than just RC-5.



--
Markus Lanthaler
@markuslanthaler

[Ytai Ben-Tsvi]

Markus,

Thanks a lot for your contribution! I'll try to review it as soon as possible, but it might take a while until I finish with the IOIO V2 stuff.

In the meantime, can you provide me and the rest of us with a short summary of what sort of protocols can be covered?

Last minor comment: I understand you're excited (for a good reason), but no need to flood the mailing list and especially threads about other subjects...

Ytai

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

[Markus Lanthaler]

Hi,

> In the meantime, can you provide me and the rest of
> us with a short summary of what sort of protocols
> can be covered?

Basically every protocol that turns a carrier of an arbitrary frequency on
and off for a specific number of cycles can be covered. An infrared command
encoded in Pronto format looks as follows. The first four words (8 bytes)
contain information about the carrier and the length of the data, e.g. (in
hex)

0000 0070 0003 0002

Specifies the frequency divider in terms of the Pronto reference clock
(0070) which is 4,145146 MHz, and the length of the following burst pair
sequences. So in this example, the carrier frequency would be 4,145146 MHz /
0x70 (=112) = 0,037 MHz = 37,01 kHz. The first, 0003 is for the once
sequence and the second 0002 is for the repeat sequence. The repeat sequence
is continuously transmitted if you keep the button pressed, e.g., increase
volume.

What follows is a sequence of so called burst pairs

0006 0002 0004 0002 0004 0006 (once sequence, 3 burst pairs)
0006 0003 0003 000С (repeat sequence, 2 burst pairs)

A burst pair specifies the time for which the carrier is on and off. So,
e.g., the first burst pair 0006 0002 says that the carrier is first on for 6
cycles or periods and then off for 2 cycles.

More information can be found at [1] and [2].

> Last minor comment: I understand you're excited
> (for a good reason), but no need to flood the mailing
> list and especially threads about other subjects...

Sorry, I didn't mean to spam the mailing list. I just replied to Siggi's old
thread as I saw some people were asking there and there was no response and
Jeff's thread on both ioio-user and ioio-dev as I knew he is working on
something very similar and I thought it would help him.


[1] http://www.remotecentral.com/features/irdisp2.htm
[2] http://www.hifi-remote.com/infrared/prontoirformats.pdf



--
Markus Lanthaler
@markuslanthaler

[Ytai Ben-Tsvi]

That looks awesome!

So, high level, before I get into the tiny details of the code, what part of the processing is done in Java and what part on the PIC?

--
Markus Lanthaler
@markuslanthaler

[Markus Lanthaler]

All IR commands are kept as integer arrays in the Java application. When you
want to send an infrared command, the modified IOIOLib sends one command to
the PIC where it is buffered (this could still be improved to not send every
word separately). Then the PIC takes over and sends that command once. This
is currently implemented as a loop as the command is usually quite short.

A better implementation would be to convert that loop to an interrupt
handler which is called every pulse_width microseconds - this would have the
advantage of not blocking the PIC while sending an IR code. I didn't need
that and didn't had the time to implement that. I think it would be rather
straightforward for someone more familiar with this PIC to make that change.



--
Markus Lanthaler
@markuslanthaler

[Ytai Ben-Tsvi]

I'm pretty strict about making everything work concurrently perfectly. I'll have a look at your code and see whether I can easily modify it to be such.

I like the idea of this general purpose IR module a lot. It might as well apply for non-IR cases (e.g. signal-channel communications over other media: electric, acoustic, etc).

It might take me a while to get to that, as I'm fairly busy lately Please don't see this as a sign for lack of interest.

Thanks!

--
Markus Lanthaler
@markuslanthaler

[Markus Lanthaler]

Sure.. I think a timed interrupt instead of the loops would do the job but I didn’t tried it as I’m quite busy at the moment as well.

 

Thanks,

Markus

 

 

From: ioio-...@googlegroups.com [mailto:ioio-...@googlegroups.com] On Behalf Of Ytai Ben-Tsvi
Sent: Friday, June 08, 2012 2:57 PM
To: ioio-...@googlegroups.com
Subject: Re: Using Infra Red via IOIO-Board

 

I'm pretty strict about making everything work concurrently perfectly. I'll have a look at your code and see whether I can easily modify it to be such.