Dangerous Prototypes

Already in SVN:
*fixed ir sample mode transmit - missed first and last TX bug
*fixed transmit timer value should be 0x10000-time, not 0xffff-time

todo:
*receiver settle time, debounce, prevent false activations
*LED on/off command

test v7 attached

Yay, transmit works now!

However, the IR Toy appears to be always receiving something. I had to block the IR receiver.

Thanks for the report. I'll continue to look into it. Here's another update, with the fixed timer value.

We also need to add a delay before enabling the receiver after transmitting because it appears to take about 200us for the receiver to settle down after we transmit.

Yeah I have the same problem here. If i send a remote signal, it appears to be receiving 'something' for about 30 seconds. And during this period I can't receive any signals because of this mysterious interference. Once the light turns off receiving works again. The problem shows up when you use the hercules utility as well.

New version with a 20x21.333 us final period. It works by sending a final 0x20 period at the end of the data. It's up to you to make sure that 0xffff falls on a blank period, or it will add a IR blast at the end.

Also added two new commands:
               #define IRIO_LITTLEENDIAN 0x05
               #define IRIO_BIGENDIAN 0x06
for byte order, but currently only the receive. I'll add for transmit tomorrow.

Need to add a transmit underflow indicator, or maybe just an ACK at the end.

1) How many subversions of V07 are there, if any? I already flashed to V07 a day or two ago.

2) A 426us final period, or a 20h period? IR blast at the end? What is this period for?

I tested the IR toy with my serial receiver. I have a feeling you are sending with some strange frequency, like 50khz, since it only seems to work at very close range.

Check this output:

tV107tV107tV107tV107tV107{00}{00}{00}{00}{00}{00}B{00}{00}{00}{00}{00}B{00}{00}{00}{00}{00}B{00}{00}{00}{00}tV107{00}{00}{00}{00}{00}{00}{00}B{00}{00}{00}{00}{00}B{00}{00}{00}{00}tV107{00}{00}{00}{00}{00}{00}A{00}{00}{00}{00}{00}A{00}{00}{00}{00}

Self-test responds with "V107", even after sending 00h (x5), and the LED stays on. Only way to turn LED off is to send 00h and press a button in the remote. Commands "v" and "t" return "V107".

1) How many subversions of V07 are there, if any? I already flashed to V07 a day or two ago.

2) A 426us final period, or a 20h period? IR blast at the end? What is this period for?

This is a development thread, there are no v07s yet, this is my work in progress for testers, use at your own risk.

The final period is 20 * 21.3333us. It is a delay so the transmitter doesn't self-activate the receiver. The Wiki has already been up-dated with this:

The transmitting LED activates the IR Toy receiver, but receive is not active while transmitting. There is a minimum 426uS delay after transmitting ends before receive resumes. This delay this gives the receiver time to recover, and prevents self-inflicted data packets.

@dukey - can you give me an example data to try? I've been testing it back and forth between two IR Toys and it looks OK. The new hardware with frequency detector also shows the correct modulation. Cold be an error in the latest firmware. I'm goign to clean it up and do a new release today.

Only development releases of v07 are available, this is probably related to debugging code or an unfinished feature.

Well, unless my reciever was almost directly line of sight, ie less than 20 cm away and facing it
I was getting this



Signal just looked totally random.

Thanks for the update. Here's another test version. This will probably be 07 final.

I checked the frequency and timing with another IR toy and a logic analyzer, everything looks pretty good now. Could you please test this and see if it's any better?

03 00 2C 00 27 00 2A 00 27 00 2B 00 27 00 2A 00 27 00 2C 00 27 00 2A 00 27 00 54 00 51 00 2C 00 27 00 54 00 51 00 54 00 51 00 2A FF FF 

I used this timing, the PLAY button on an RC5 remote, received in RX mode and retransmitted in TX mode.
*In RC5 decoder mode the received IR toy correctly decoded this to 1e 75 00 00 00 00.
*In IR sample mode the RX IR Toy gave timing within 1 or 2 of the transmitted signal
*On a logic analyzer connected to the demodulator and frequency detector, both the modulation frequency and RC5 bit times look good
*tested from across the room to get an idea of range. It looks like range is OK, but it has to be pointed the right way with the prototypes. The LED on the prototype is a very directional emitter (not sure about the true emitter-style on the manufactured version).

{06}{00}{E5}{02}{30}{03}{7C}{01}{C3}

Here is the freq report (http://http://dangerousprototypes.com/docs/USB_IR_Toy:_Sampling_mode#Frequency_report_.280x04.29) from the updated hardware from a transmission from the current IR Toy (poor sentence there).

The signal period is 0x14B, which is really close to 36khz.

Note that the extra commands (for v07) are still in flux, here's the IR sample commands for this version:
#define IRIO_RESET 0x00
//1 and 2 reserved for SUMP RUN and ID
#define IRIO_TRANSMIT 0x03
#define IRIO_SETUP_PWM 0x04
#define IRIO_SETUP_SAMPLETIMER 0x05
#define IRIO_FREQ 0x06
#define IRIO_LITTLEENDIAN 0x10
#define IRIO_BIGENDIAN 0x11
#define IRIO_LEDMUTEON
#define IRIO_LEDMUTEOFF
#define IRIO_LEDON
#define IRIO_LEDOFF

---

I updated the Wiki with the latest commands and more documentation:
http://dangerousprototypes.com/docs/USB ... e#Commands (http://dangerousprototypes.com/docs/USB_IR_Toy:_Sampling_mode#Commands)

Note some commands changed again (not transmit).

I added these features for v07:
*Transmit fixed (hopefully)
*LED on/off/mute commands
*Sample timer setup
*Transmit frequency modulation setup
*Byte endianness adjustment
*Fixed hardware version detect (now solid)
*Cleaned most code (could be new errors)

Would still like to, in future firmware:
*do lots of testing, confirm stuff works for you
*add buffer underrun error for transmit mode
*make IR sample the main mode
*add bitbang commands for new hardware (input/output, high/low).
*USB to serial bridge mode
*Create a compile of IR Toy firmware for the Hack a Day ir receiver hardware

I like the IRMan mode as default. It is a simple protocol that works well for controlling a media PC without having to change the IRToy mode on startup.

Universal controls with RC-5 codes are plenty and they can control more than one device.

The interesting thing about teh IR man protocol is that it is supposed to send "IR" at the start, and the IR Toy says 'OK'. So IR sample mode could just branch to IRman-compatible mode when it got the "I" part of IR.

The IRToy stopped working after a momentary loss of power and PC reboot.  Restarting the PC again shows the IRToy's LED turns on, but it doesn't work, and reset (0x00) has no effect. I see no response from the IRToy in Hercules. I suspect small power fluctuations can affect the IRToy (directly or indirectly), I have it connected to a PCI USB card. Turning the PC off then on fixed it.

When the IRToy is in IRMan mode it responds to other commands like "v" (V107), "t" (not working in V107), or "r" (OK), which is a good thing for the default mode to do.

Sampling mode doesn't respond to any commands, not even "s" (a second time for code to verify current mode), a behavior that might seem unresponsive for a default mode.

t is not working in v07?

All those behaviors would be present if sampling was the main mode. All the commands were purposefully kept out of the current sampling command space.

Every time I press "t" I get "V107" and the LED turns on. Sending 0x00 and pressing a button in the remote will turn the LED off.

Yes, those things will be present when it becomes the main version.

Every time I press "t" I get "V107" and the LED turns on. Sending 0x00 and pressing a button in the remote will turn the LED off.

That is the correct behavior:
http://dangerousprototypes.com/docs/USB ... on#Results (http://dangerousprototypes.com/docs/USB_IR_Toy:Self-test_documentation#Results)