Dangerous Prototypes

I am completely outta my league here, so if you guys think I should look elsewhere, I don't mind if you say so.

I'm just a simple vb.net programmer who was looking for a less expensive alternative to the expensive USB-IRT, or TIRA currently
on the market.  In my mind I picture plugging the toy into a USB port on my computer, shooting beams from my remote control at it,
using my own program to store those codes in a database, and playing them back from the toy later from my PC to control various equipment.

I thought I had what I needed with the Toy, but now I am not so sure.  Do I need additional equipment for the scenario I described? (I know the thing needs a case -- even that is more complicated than I ever imagined.)

Also, somehow I will have to integrate the code supplied into a vb.net class.  Has anyone already done this?

I appreciate any feedback you guys can provide.  Thanks in advance for your help.

Hey codefinger - you should be able to do that with the IR Toy. Receive raw remote samples in RAW ir mode, then send the data back (you'll have to reformat it to the 7bit transmit protocol) to retransmit it.

As far as I know, there currently no utilities or existing VB code for the IR Toy, but there might be something in the forum.

"You don’t need a driver to use the USB IR Toy, but you will need a .inf file to tell Windows how to use the device. A suitable .inf is included in the project archive."


I am new here.  Where is the "project archive"?


Thanks.

Here's the latest download:

http://code.google.com/p/dangerous-prot ... y.1.02.zip (http://code.google.com/p/dangerous-prototypes-open-hardware/downloads/detail?name=USBIRtoy.1.02.zip)

USB IR Toy manual (http://http://dangerousprototypes.com/usb-ir-toy-manual)

USB IR Toy HowTo (http://http://dangerousprototypes.com/2010/01/29/prototype-usb-infrared-remote-control-receivertransmitter/)

USB IR Toy Package (http://http://dangerous-prototypes-open-hardware.googlecode.com/files/USBIRtoy.1.02.zip) - includes the .inf file you need when connecting the USB IR Toy to your Windows PC for the first time.

Next you may want to play around with it and test the basic fuctions.  The Hercules Setup Utility (http://http://www.hw-group.com/products/hercules/index_en.html) and RealTerm (http://http://sourceforge.net/projects/realterm/files/) are free and good tools to start hacking the USB IR Toy ... on the PC it can be accessed as serial (COM port) device. ;)

I think everyone else has already answered your basic question, but I wanted to specifically state that you can do what you want without buying any more hardware at all.  In fact, you don't even need a case if you're careful.

I'm on a Mac, and I've written my own software. You just open the USB IR Toy like a serial port and then send and receive bytes to implement the commands.

I had thought that I might "improve" the firmware, since I already have all the tools necessary for that, but so far I have not needed anything beyond the existing functions.

Ok, I was able to install it with the inf file and as far as I can tell, it's getting along fine with Windows XP.
I also downloaded RealTerm.   When I shoot my remote beams at the connected USB Toy, it lights up, but
on RealTerm, no matter what settings I try, nothing happens.  I do not see any data coming in. 

Can someone advise what I might be doing wrong?

Thanks!

When I shoot my remote beams at the connected USB Toy, it lights up, but
on RealTerm, no matter what settings I try, nothing happens.

Two things you might check:
1. The default decoder only works with RC5 remote controls, though someone has submitted code with more protocols that might be integrated soon.
2. Name sure realterm is set to display HEX formatted values, not just ASCII. I don;t know realterm, so I'm not usre how to do that.

For rawIO mode, you;ll need to check the article and find the command to send to put the IR Toy into rawio mode (X, i think?). Then you can get raw samples of the IR signal.

That did it!  Thanks!

Comparing the remote codes I receive in my program with the ones displayed by the same remote signal from RealTerm has shown me my byte array is too short.  IOW,  my program stops receiving/listening before IR Toy has finished sending.   Is there any kind of end-of_stream character I should be searching for, or a way to query the IR Toy to see if the signal has completed?

(I know, RTFM, and I am trying to understand it but its a little over my head.)

Thanks in advance for any and all assistance you guys are willing to provide.

The IRIO mode waits until 5 identical bytes are captured, then stops recording and sends the result. You should be able to look for the same sequence of 5 identical bytes for your program's EoS marker.  I can't remember for sure if it's 5 bytes, but that would be 40 samples (5 bytes * 8 bits each).  If you skim TFM :-) you should find this information.

My OSX program is working in IRIO mode. I have it constantly in receive mode - i.e. it never stops receiving.  Bytes are simply decoded and sent to the display after a 2-second delay.  I really should implement that scan for EoS, but it works quite well with the 2-second delay as it is.

You might try refactoring your program so that it is not procedural.  In other words, don't send a command, wait for a response, and then stop.  Instead, you should have the receiver code always in operation.

Are you using the IRIO mode? If so, the data just goes as long there's IR activity. There's really no way to know when the samples will stop. The IR toy will capture samples until 5 bytes go by with no activity (0x00 x 5). You might look for that, but there's no guarantee that more data won't follow.

As far as your buffer - The IR Toy uses a 64byte buffer, so I'd start by expecting 64byte max per 'read' from the serial port, but again no guarantee of how much data there will be or when the next lot will arrive.

Just tried this out with my OSX client, and I should warn you that you might get a string of five 0x00 bytes at the beginning of a IR command, between the start pulse and the command/address.  Not sure whether the Toy considers this two messages or one.  Sometimes, though, the timing alignment happens such that there are only four 0x00 bytes in that position.

I think the best approach might be to reset a timeout with every byte received, and if the timeout expires then display the collected data.

Thanks again for all the help guys.   With the hints you gave me, I was able to adjust my program so the codes received
match the RealTerm codes...all of them.   (Although they seem to break differently when copied into NotePad, I hope that is just the effect of a terminal display vs a textbox display.)

So I THINK I have receiving working.   Transmitting, however, is another matter.   I've tried just sending the same codes I received back to the Toy, but it has no effect on the target machine. Some one said I needed to re-format the transmission to the 7-bit protocol.  rsdio, is that what you do for a transmission from your Mac?   Or do you just send out the
codes exactly as you received them from the remote?

As always, any and all help is appreciated.  Thanks in advance.

The default mode is 7bit transmit. You send a byte with bits 1xxxxxxx where 1 tells the IR toy to transmit, and xxxx are the bits. The reived data is 8bits xxxxxxxx where all 8 xs are data bits. To retransmit from default mode, you;ll need to break the xxxxxxxx into 1xxxxxxx and 1xyyyyyy where x are the a data bits, and y is the next byte or 0's if it's teh last byte.

The other thing you can do is use the 8bit transmit mode command to put the IR toy in 8 bit retransmit mode. Then, every byte xxxxxxxx is considered data. The down side to this is there's no way to tell the difference between data and commands, so you;re stuck there and have to reset the IR Toy to get out of that mode, modify timing, etc.

So far no joy.   I can capture the input as bytes that look like this on my textbox display:
 127 254 63 254 62 0 63 254 31 254 31 0 31 0 15 0 15 0 15 255 143 128 7 128 0 0 0 0 0 127 252 63 252 60 0 63 254 31 254 30 0 30 0 31 0 15 0 15 255 15 0 15 128 0 0 0 0 0 127 252 63 252 60 0 63 254 31 254 30 0 30 0 30 0 15 0 15 255 15 0 15 128 0 0 0 0 0 127 252 63 252 60 0 63 254 31 254 30 0 30 0 30 0 15 0 15 255 15 0 15 128 0 0 0 0 0

....and according to the last post, the following approach SHOULD play it back...

prt.Write("1")

            For Each b In codes
                sbitval = Me.ConvertBytetoBits(b, str_resp)
                prt.Write(sbitval)
            Next

            prt.Write("0 0 0 0 0")

So far no joy.

If I understood the last post correctly, the following code SHOULD play back the code to the toy
and allow it to control the device.   Where port is the Com port, and codes is the byte array where
the received bytes were stored.  

            dim b as byte
            dim sbitval as string

            prt.Write("1")

            For Each b In codes
                sbitval = Me.ConvertBytetoBits(b)
                prt.Write(sbitval)
            Next

            prt.Write("0 0 0 0 0")

Regardless of the programming language, any one of you guys who can code at all can hopefully figure out
what I am doing wrong and help me out.

Thanks in advance!

It would probably be best if you could describe what you intend for this code to do.

prt.Write("1")

What is this supposed to do? IF it's ASCII string it's 0x31 (?), if it's an actual byte value it's 0x01 which is the timer setup:

Commands

    * Reset 0×00 (returns to remote decoder mode)
    * Setup sample timer 0×01 (send 2 bytes)
    * Setup TX modulation 0×02 (send 2 bytes)
    * 8bit TX enable 0×03

Also, what is ConvertBytetoBits(b) supposed to do? If you received serial port data it should already be held as a byte.

Finally, why do you end with 0x00 x 5? And it looks like there's spaces in there so you;r probably actually sending 0x30,0x20,0x30,0x20, etc (sorry, ASCII code is not my stong point, I didn;t look these up, might not be actualy value).

You might consider running  portmon on the virtual serial port while you communicate with teh IR Toy, that will show you exactly what you;re actually sending to it.

Hey Ian, what I am trying to do is what I think you thought you were telling me to do.  prt is the port (sorry, should have made that clear)  Goal is to use the received data to affect the target device from the PC.

"The default mode is 7bit transmit. You send a byte with bits 1xxxxxxx where 1 tells the IR toy to transmit, and xxxx are the bits. The reived data is 8bits xxxxxxxx where all 8 xs are data bits. To retransmit from default mode, you;ll need to break the xxxxxxxx into 1xxxxxxx and 1xyyyyyy where x are the a data bits, and y is the next byte or 0's if it's teh last byte. "

"what is ConvertBytetoBits(b) supposed to do? If you received serial port data it should already be held as a byte"

Yes, it is held as a byte array as it was received.  But to transmit the code to the port so it affects the target device, I have to transmit it as bits. So each byte has to be turned into bits before being sent to the port.

Your post seemed to indicate that sending a "1" was necessary to tell the IR toy to transmit, so that is the reason for the
prt.Write("1").   But now I see that may have just been your shorthand for a bit, so that just sending a bit may be enough to tell the
IR toy to transmit.  

I checked the output in my software debugger and I am sending a stream of 1's and 0's.

The 0's were supposed to indicate to the IR Toy that it had received the last bit.....the spaces were just wrong.

Sorry if I seem a bit dense.  Have I mentioned I am outta my league?  I've never worked with bitstreams before and I am learning as I go.   I appreciate your help and your patience.

I see the confusion :) The 1xxxxxxx are the bits of a byte, not individual bytes of 1 and 0. So if the value you want to send is 255 (0xff, 11111111), then you'd need to send 11111111 (0xff, 255), 1xxxxxxx plus the first 7bits of the byte received (x1111 111). Next, send the last remaining bit in a second command: 11000000 (0xc0, 192) where 1xxxxxxx is transmit bit again, the second 1 (x1yyyyyy) is the last 1 bit of the received byte, and 000000 are nothing because we have no additional data (if you had two bytes then 000000 would be the first six bits of the next byte).

127,254=01111111, 11111110
So, you;d send
10111111, 11111111, 11000000 = 191, 255, 192
And the break down is like this (bold first byte, underline second byte):
10111111, 11111111, 11000000 = 191, 255, 192

has anyone succeeded in doing what I am attempting using the USB IR Toy?  That is, use a PC (or even a Mac) to transmit a remote control code through it that affects a target device?   If so, would you mind sharing your code with me?  I may not understand the language per se, but I may be able to get the gist of it.

Thanks in advance.

In the article I used a simple terminal program to repeat the bytes back from 8bit transmit mode, that might be an easier way for you to get started. rsdio mentioned his Mac program earlier in the thread, the discussion is here:
http://dangerousprototypes.com/forum/in ... opic=520.0 (http://dangerousprototypes.com/forum/index.php?topic=520.0)

I contacted rsdio privately, but his Mac program only captures and displays the data.  As far as I can tell now, no one has used the USB IR Toy to actually transmit the captured codes from their PC to control a device. 

I don;t know of any other utilities yet. I test with a serial terminal and a Perl script that both use 8bit retransmit mode.

From looking at your earlier code it seems to be inconsistent on the data type, as well as bits and bytes.

For example:

prt.Write("1")

"" usually says 'this is a string', so instead of sending the IR toy 0x01 the raw byte value, you're sending the ASCII value "1" (see http://www.asciitable.com/ (http://www.asciitable.com/)) which is actually 0x31.

Maybe what you need is prt.Write(0x01) or prt.Write(1) or

unsigned char c;
c=1;
Write(c);

You can debug this by checking what gets sent to the IR Toy on portmon. Is it actually the intended value?

            dim b as byte
            dim sbitval as string

            prt.Write("1")

            For Each b In codes
                sbitval = Me.ConvertBytetoBits(b)
                prt.Write(sbitval)
            Next

I'm guessing this is BASIC? I don't know this language, and I can only really give you an example in C-like languages.

My best guess for 8bit mode is below. I'd suggest you get 8bit mode working before trying to reorder bits because it's going to be easier if you're just staring with bits and char variable types.

 
function setup (){
            prt.Write("X") //send ASCII X to go into raw IO mode
//do something here to process the reply
            prt.Write(3) //send 0x03 to go into 8bit transmit mode, notice no ""
}


function send_array (var_type_array codes[]){
           dim c as byte //don't know baout type, but the link below suggests byte type

            For Each c In codes
                prt.Write(c) //is this right for your language? some might be codes[c]
            Next
}

Again, use portmon and make sure the bytes you intend to send are going to the IR toy. If not, check the variable typing, you may also need to add things like char() hex() dec() as needed to shift between types.

This basic framework can be modified with a control loop or two to use bitwise operators to reshuffle the bits as in my example above.

The first hurdle seems to be variable type:
http://msdn.microsoft.com/en-us/library ... 80%29.aspx (http://msdn.microsoft.com/en-us/library/47zceaw7%28VS.80%29.aspx)
http://www.techotopia.com/index.php/Und ... tant_Types (http://www.techotopia.com/index.php/Understanding_Visual_Basic_Variable_and_Constant_Types)

Then bitwise operators and how bits go together to make a byte:
http://en.wikipedia.org/wiki/Bitwise_operation (http://en.wikipedia.org/wiki/Bitwise_operation)
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B (http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B)
http://www.cprogramming.com/tutorial/bi ... ators.html (http://www.cprogramming.com/tutorial/bitwise_operators.html)
http://www.eskimo.com/~scs/cclass/int/sx4ab.html (http://www.eskimo.com/~scs/cclass/int/sx4ab.html)

[quote author="codefinger"]
I contacted rsdio privately, but his Mac program only captures and displays the data.  As far as I can tell now, no one has used the USB IR Toy to actually transmit the captured codes from their PC to control a device.
[/quote]I have not been successful yet either. I have just given up for the time being.

Until I hear that someone else has actually done it (controlled a device by transmitting captured remote codes from their PC using the USB IR Toy), I am also abandoning this effort.

Thanks, guys, (especially Ian) for all your help and patience.


L8r

I can confirm that it works in these situations:
1. One IR toy transmits an RC5 code to another IR Toy in RC5 mode, as shown in the how-to
2. A logic analyzer capture of the receiver output on the receiving IR toy looks right
3. Captures of a Hauppauge remote control for a WinTV PVR will control my MythTV box
4. Captures of my living room (non-PC) media player remote turn it off and on

All of this is done in 8bit mode with captures from a terminal returned to the IR Toy via a terminal (Herculese from hw-group.com).

There's a lot of mixing of ASCII and byte values in your original code. Can you post your updated code? I'll see if I can help somehow. How does it look on portmon, are the values looking better?

If anyone has record/transmit code to test or review, I'm happy to help. I can also run the code while the IR Toy is on a debugger to figure out if there's firmware errors.

Hey Ian.

Its pretty clear we are not speaking the same language, which is my fault.   I over-estimated my ability to translate.
However, I have decided to recruit a translator from RentACoder because it is worth it to me.   So in your example, what language
were you using to control the Toy?

Thanks.