"USB Infrared Toy" with Netduino 3 WiFi

[noob warning]

 

Before I got Netduino, I successfully played with USB Infrared Toy from Dangerous Prototypes. I managed to send/receive IR from C# based application via USB.

 

So, now I am wondering if it will be possible to connect it to Netduino 3 and control it from the board.

 

Do any of the books describe how to connect devices? Also, how do I know that the boards designed for Arduino (or any board like this USB Infrared Toy) are compatible with Netduino?

 

 UsbInfraredToy.jpg   90.37KB   0 downloads

 

Thanks!

Hi tridy.net,

Looking at the product page for the USB Infrared Toy really quickly...

Do the UART pins on the Toy carry the same data as the USB transport? If so...

What signal voltage do the UART serial pins use? If they're 3.3V (or 5V with 3.3V signal recognition) then there's a good chance that you can reuse some/all of your desktop C# code on your Netduino 3, using SerialPort. Just wire up UART TX/RX between the Netduino 3 and the Toy (crossing RX/TX of course)--and connect GND between the two boards so they share a common electrical return path (GND).

Chris

Thanks for the reply.

 

Here is what I have found on the description of the IR Toy:

(http://dangerousprot...2#Breakout_area)

 

Everything runs at 5volts, so power is taken directly from the USB port without regulation. A single power supply pin gets a 0.1uF decoupling capacitor (C1). The USB features require a 20MHz external oscillator (Q1, C5, C6).

 

The chip is initially programmed thorough a 5pin ICSP header. A 10K pull-up resistor (R1) and a diode (D1) on the MCLR pin protect the rest of the circuit from the 13volt signal used during programming.

 

An indicator LED (I) with 2K current limiting resistor (R2) displays power, USB, and infrared mode status.

The USB transceiver has an internal 3.3volt regulator that requires a 220nF (0.22uF) external capacitor (C2).

 

So, it seems like it's worth trying to connect them, like you described.

 

Just wire up UART TX/RX between the Netduino 3 and the Toy (crossing RX/TX of course)--and connect GND between the two boards so they share a common electrical return path (GND).

Chris

 

However I got lost here.

 

3 connections on Toy:

• UART.RX
• UART.TX
• ICSP.GND

 

should be connected to ones on Netduino:

• ??
• ??
• Power.GND (there are 2 of them, does it matter to which one?)

 

 CrossingNetduinoIrToy.jpg   94.12KB   0 downloads

 

thanks a lot for the help!

 

Hi tridy.net,

All three GND pins are connected to the shared GND plane...so all of them will work equally. Electricity always flows "toward ground" in the end, so for two devices to communicate they typically need a common GND plane.

On the connection, there's a pinout reference in the right column of the Netduino 3 Wi-Fi specs page:
http://www.netduino....3wifi/specs.htm

? digital pins 0-1: UART 1 RX, TX
? digital pins 2-3: UART 2 RX, TX/PWM
...
? digital pins 7-8: UART 3 RX, TX
(also works as UART 2 RTS, CTS)
...
? digital pin SD/SC: SDA/SCL
(also works as UART 4 RX, TX)

UART 1 = COM1. UART 2 = COM2. Etc.

Does that get you on the right path?

Chris

Thanks, Chris!

 

here is the path I have got on:

1. Toy.UART.RX > Netduino.DIGITAL.0
2. Toy.UART.TX > Netduino.DIGITAL.1
3. Toy.ICSP.GND > Netduino.DIGITAL.GND (or any ground)

 

one last thing before I connect it is the "crossing RX/TX of course" . Does it mean that Toy.RX should go into DIGITAL.1 and Toy.TX into DIGITAL.0? or did I get the meaning of "crossing" wrong?

 

thanks!

Hi tridy.net,

As you surmised, the UART TX on the Toy needs to go to UART RX on the Netduino (and vice-versa). That was the Netduino is getting the signals sent by the Toy and the Toy is getting the signals sent by the Netduino.

So...swap your pin D0/D1 connections and you should be good to go as far as logic wiring is concerned.

Chris

Soldering done, pins connected and now more questions.

 

 connected2.jpg   64.25KB   1 downloads

 

As far as I understand, it does not need extra power supply, is this correct?

 

So, now this device is both input and output.

 

Probably, for a start, the most straitforward would be to get the status that the device is "listening"

Then try to send a signal from a remote control and see if it triggers an event and gets some data.

 

Since I will be sending the signal to the device, I should probably create an InputPort and AnalogInput but I am not sure about glitchFilter flag and ResisorMode.

 

Could you please give me some hints.

 

Thanks a lot!

 

Hi tridy.net,

First step: you need to supply power to your device How are you powering your device?

You currently have the signals set up (like connecting a serial cable from your computer to a device) but you need power too. Signals are just a communication pathway; as a general rule signals won't power chips.

You can use the 5V and 3V3 (3.3V) headers on the Netduino to power your device, if it accepts external power. Orperhaps power the device via its own USB connection?

Chris

Hi.

 

I've got the power now I connected 5v from Netduino. I will try the exteranl USB some time later. (By the way, could it be so that when I connect the USB to the Toy, it will "think" that I will be using the USB for the data connection as well and disable the data pins?)

 

so, the light is on and hopefully I am ready to program the communication:

 

 +5v.jpg   71.43KB   1 downloads

 

Am I ready for the step 2?

 

Thanks!

My hopes for making [USB] Infrared Toy work are fading away. I went into testing communication between the Toy and PC and make sure that it can get the basic commands go through, such as getting the version from the Toy. It worked while connecting via USB but Serial via my USB-To-Serial adapter does not go through.

 

I have posted a question on the DangerousPrototypes forum and hope that someone might give me a hind if I am doing something wrong. http://dangerousprot...php?f=29&t=7214

 

it's strange that I could see that some data gets into the terminal via Serial, but if I compare USB via Serial again, the USB delivers proper data, and Serial data is just a bunch of garbage {Null}, {F0} and {F8} bytes.