Jump to content
  • 0

Workaround for EEBoard 512 bit buffer limit.


CharlesS

Question

Hello all,

I'm experimenting with IR remote protocol using an IR LED and a typical TSOPxx38 IR receiver, all on the Digilent Electronics Explorer board, and I am in need of a work around for sending more than 512 bits on a single DIO channel. I have searched through WaveForms' help and could not find anything of use on this.

 

Synopsis
Typical IR coms work, in principle, identically to ON/OFF keying in radio. That is, an IR receiver sees a logical 0 as the absence of the carrier, and a logical 1 as the presences of the carrier. The difference from radio being that the carrier in IR coms is realized as an IR light flashing at 38kHz. The actual intelligence is sent as varying lengths of carrier/no carrier to construct higher-level 1s and 0s. I will label those here as "mark" or "space" tokens or symbols.

I am trying to emulate this process using WaveForms' Digital Pattern Generator via the Electronics Explorer board and a single DIO pin.

 

Efforts
The first thing I tried was to configure a pin as a 38kHz clock and send pulses by simply running or stopping the Digital Pattern Generator. This emulated the carrier properly; the IR receiver indeed changes logical state when the DPG was enabled/disabled. However, this does not allow algorithmically controlled mark/space patterns to be sent, such as what you would see with a button press on a TV remote.

Next, I tried to set a custom signal type, pre filled with alternating 1s and 0s. Then, to construct a high-level pattern, I simply copy and paste 1/0 blocks for mark, or high-Z blocks for space. This worked as expected, and the high-level pattern I create does indeed show up on the IR receiver output pin. The problem is each 1/0 block is composed of several bits, consuming a rather large portion of the buffer. If a mark consists of 32 bits, and a space consists of 32 bits, I can only send about 8 tokens/symbols with the given buffer size. Since a typical consumer electronics remote may send something around 10~25 symbols, this method proves to be inadequate.

My final idea (something I have yet to actually try) would be to use one DIO as a 38kHz clock that is constantly on, and a second DIO plus some switching component (read:transistor) to either pass or block the clock to the LED. This would let me use the full 512 bits of the second DIO channel to send the marks and spaces. This idea leaves a sour taste in my mouth though; I feel that this platform should be able to do this simple a task no sweat without me having to resort to adding such hardware hacks.

Final Thoughts
According to the EEBoard's datasheet, the device should have "... up to 16KSa per pin buffer depth." This is great... but what exactly does this mean? Where is this "16KSa per pin?" Because I'm not really seeing a way to send 16Kb on one wire. Seems to me this 16KSa is actually the 512 bit buffer per pin, times the 32 pins. So really it looks like it should say something like "512Sa hardware buffer per pin, for up to 16KSa total buffer size," or similar. I have searched through WaveForms' help and could not find anything of use about this either.

Clarification on this last point, and help in general, would be greatly appreciated. Thanks.
-Charlie

Link to comment
Share on other sites

2 answers to this question

Recommended Posts

Hello,

 

The EExplorer and Analog Discovery have several configurations available with different device buffer-memory distributions for the instruments and different instrument support.

To select one of these, in WaveForms (2.x) main window under Device/Manager select "Show advanced features". This will make the configuration list visible.

Link to comment
Share on other sites

Ah! I see now. Hooray for programmable logic  :) 

Interestingly, I used the search on the left of WaveForms help for the keyword "buffer" and the page that explains device manager never showed up. (I guess that the find text box is different from Ctrl+F) If that wasn't enough, I had already read the page in question, but apparently didn't really take in that particular piece of info. Hindsight is 20/20 I guess.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...