Dangerous Prototypes

Dangerous Prototypes => USB Infrared Toy => Topic started by: ian on July 08, 2010, 10:08:04 am

Title: USB IR Toy update
Post by: ian on July 08, 2010, 10:08:04 am
This is a moderate update of the IR Toy to be prototyped this summer and available maybe next year. Let us know what you think.

Changes:
*Added QSE159 for frequency counter
*Frequency counter connected to both async timer (1 second count) and input capture (period measurement)
*Extra pins to header
*1uF supply cap for IR LED
*No via in USB traces

V1.0 will go CC-0 (or BY SA) when this replaces it.
Title: Re: USB IR Toy update
Post by: rct on July 08, 2010, 03:11:58 pm
[quote author="ian"]
Changes:
*Added QSE159 for frequency counter
*Frequency counter connected to both async timer (1 second count) and input capture (period measurement)
[/quote]

This might be a little too early for me to reply (in several ways), and I'm probably misunderstanding things, but here goes:

I'm confused by the reference to the 1 second timer to determine frequency?   Won't that give the wrong results since no IR signal would be sending a carrier for that long?

The IR Widget (hardware) as I understand it counts the number of pulses in 100 us samples.  The software (IR scope) depends on having three consecutive 100 us samples (approx. 300 us minimum on time) to determine carrier frequency.  The middle sample should then contain the count of pulses for when the carrier was being sent for the whole 100 us sample. 

In order to count pulses reliably wouldn't you need the detector be connected to an interrupt capable pin?

Thanks,
Title: Re: USB IR Toy update
Post by: ian on July 08, 2010, 03:18:25 pm
The async timer is a counter driven by edges on the external pin. So start the counter, start any length timer, stop the counter on interrupt, and you have a count. The reference to 1 second was just a (poor) example that it would count over time, instead of measuring a single period. It's probably a really good idea to also connect it to an interrupt pin (INT1?) so we can trigger the sequence only on the start of the signal (first fall of the detector).

*Ensure frequency counter can be started on first edge (INT1 connection or counter interrupt, or period timer edge interrupt).
Title: Re: USB IR Toy update
Post by: rct on July 08, 2010, 05:50:15 pm
Thanks for the explanation.   For my own education, if you also tie this to an interrupt pin (INT1/RB1) to capture the first edge and start the timer, will you still connect it to the other two pins (RC0 & RC1)? 
Title: Re: USB IR Toy update
Post by: ian on July 08, 2010, 06:45:53 pm
I need to spend some more time with the datasheet to be sure. My assumption was that I could use the timer (counter..) or CPP interrupt on the first edge to do what I want. For example the CCP offers these options:

Code: [Select]
15.2 Capture Mode
In Capture mode, the CCPRxH:CCPRxL register pair
captures the 16-bit value of the TMR1 or TMR3
registers when an event occurs on the corresponding
CCPx pin. An event is defined as one of the following:
• every falling edge
• every rising edge
• every 4th rising edge
• every 16th rising edge
The event is selected by the mode select bits,
CCPxM3:CCPxM0 (CCPxCON<3:0>). When a capture
is made, the interrupt request flag bit, CCPxIF, is set; it
must be cleared in software. If another capture occurs
before the value in register CCPRx is read, the old
captured value is overwritten by the new captured value.

So the first X edge triggers one capture that measures the period, then we get an interrupt (it doesn't look like first-edge interrupt is an option), then we could take the 3 x 100uS counts using timer 1 as a counter and timer 0, 2, or 3 as a timer. If we want everything to begin absolutely on the first edge, then we should start with an interrupt INT1 or something. All three pins would be connected to the detector output.
Title: Re: USB IR Toy update
Post by: ian on July 08, 2010, 06:50:13 pm
I really think this should be done, even if we end up not needing the INT1 interrupt. It gives the most options.

My idea is also to compare the period differences during the capture to detect any 'dead' spots during a frequency measurement. It can then include some vague indicator or reliability for each frequency measurement. (I don;t know if that's at all clear)
Title: Re: USB IR Toy update
Post by: ian on July 08, 2010, 07:03:58 pm
Actually, it looks like the CPP IF is set on every edge (image attached).
Title: Re: USB IR Toy update
Post by: rct on July 08, 2010, 08:59:01 pm
[quote author="ian"]
My idea is also to compare the period differences during the capture to detect any 'dead' spots during a frequency measurement. It can then include some vague indicator or reliability for each frequency measurement. (I don;t know if that's at all clear)
[/quote]

I don't follow the dead spot detection / quality indication.  I'm sure you've got it all well in hand and I just don't understand.

As far as I understand, the ir widget doesn't do any frequency measurement in the hardware, it happens in software.   It's just reporting pulse counts in 100 us samples.  I believe it allows for capturing of macros that contain multiple IR signals for different devices which could have different carrier frequencies. 

(Some of the ir widget devices could measure the on/off period durations or the pulse counts, depending on the setting of RTS (I think).   It can't do both at the same time.  I believe the IR widgets that are now being sold only do pulse counts with an IR led or detector.  The current maintainer of irscope only tests pulse counts though looking at the source the ability to process the durations may still be in place.  IR demodulators aren't used any more because they return skewed durations for the on periods.)

I'm not clear if you are just going to be counting pulses until you make a frequency determination or will be making all of the pulse counts available to the host.  For irscope mode, the later is needed.     If you could swing reporting the durations and pulse counts to the host for the same signal, then I suppose you'd have the best of both worlds in trying to come up with the most accurate reproduction of the signal. 
Title: Re: USB IR Toy update
Post by: rsdio on July 08, 2010, 09:22:32 pm
Ouch, those three headers are very close together!
The programming header is 5-pin, but many Microchip programmers are 6-pin. Due to the orientation you've selected, that would require connecting a 6-pin cable over the RX signal on the Serial Port header.

It might be better if you could flip the programming header 180 degrees, so that a 6-pin cable would just have the extra pin over empty space.

Ideally, there would be clearance around the programming header so that a PICkit 2 or 3 could be directly attached to the board, but I guess you're going for an extremely compact design here.
Title: Re: USB IR Toy update
Post by: rsdio on July 08, 2010, 09:26:18 pm
Have you given any consideration to the constant-current transistor circuit that I mentioned way back? Adding a couple of diodes and a resistor would make it possible to set a specific LED current, regardless of whether some people get 4V or 5.25V on their particular USB port.  I believe it would even be possible to make this optional, or at least part of the circuit (i.e. I think you could leave out the diodes but have the pads there for experimenters like myself).
Title: Re: USB IR Toy update
Post by: rct on July 09, 2010, 12:54:17 am
Now that the extra pins are available will there be any provision in the stock firmware for indicating which pins should be used for sending IR output?   Perhaps something like a mask?
Title: RF, RS232C support?
Post by: TEN on July 09, 2010, 08:01:07 am
[quote author="ian"]
This is a moderate update of the IR Toy to be prototyped this summer and available maybe next year. Let us know what you think.

Changes:
*Extra pins to header[/quote]

Will the firmware support RF module RX/TX connected to this JP1 expansion (like IR but just TTL with the softcarrier switched off) ?

While obviously there is no space for an optional MAX232, firmware support to use the serial port at least for an lcdproc-style output would of course be a welcome addition as well.
Title: Re: USB IR Toy update
Post by: ian on July 09, 2010, 08:32:35 am
@rsdio - There are seperate headers, but it's supposed to be one prototyping area. The TX pin should be hiz during programming (and in any current firmware), so it shouldn't matter with the pickit2 extra pin. Do you know if that pin is NC or has some other use? We did look at the constant current driver, but it didn't make this revision. It's definitely something that got a lot of debate and will be in a future update.

@rct - Unfortunately the IR TX is done by a hardware PWM that is only available from fixed pins. There is one attached to the IR LED, and another that we'll use in capture mode to measure the raw IR signal period.

@TEN - Both of these thing should be possible with the current hardware with some firmware changes. The first one I can implement probably next week if you're eager to experiment.
Title: Re: USB IR Toy update
Post by: rsdio on July 09, 2010, 02:48:31 pm
[quote author="ian"]
@rsdio - There are seperate headers, but it's supposed to be one prototyping area. The TX pin should be hiz during programming (and in any current firmware), so it shouldn't matter with the pickit2 extra pin. Do you know if that pin is NC or has some other use? We did look at the constant current driver, but it didn't make this revision. It's definitely something that got a lot of debate and will be in a future update.
[/quote]
The AUX pin is not NC on the PICkit 2 or 3. It can be used for various purposes, including a simple 3 channel logic analyzer.
Title: Re: USB IR Toy update
Post by: rct on July 09, 2010, 03:18:46 pm
[quote author="ian"]
@rct - Unfortunately the IR TX is done by a hardware PWM that is only available from fixed pins. There is one attached to the IR LED, and another that we'll use in capture mode to measure the raw IR signal period.
[/quote]

That is unfortunate.  I was hoping to have multiple remote IR outputs.    If it is not too late, can you bring RC2 out to the header to allow for those who might want to add different driver circuits (like rsdio is asking) and possibly remote the IR LED?
Title: Re: USB IR Toy update
Post by: ian on July 09, 2010, 03:29:17 pm
Absolutely, thanks.

*RC2 to header
* IR Led driver to header
Title: Re: USB IR Toy update
Post by: rsdio on July 09, 2010, 09:35:07 pm
Is there any disadvantage to flipping the programming header around 180 degrees?  That would put the AUX pin over nothing, which is guaranteed not to conflict with any programmer's circuit.
Title: Re: USB IR Toy update
Post by: rct on July 11, 2010, 08:49:50 pm
[quote author="ian"]
Absolutely, thanks.

*RC2 to header
* IR Led driver to header
[/quote]

Thanks that should be useful for driving other IR LED outputs.

I went back and looked at the Nirvis Slink-e (http://http://nirvis.com/schemati2_0.htm) to see how it had 8 IR outputs with a PIC 16C67.  It looks like it is using a single PWM line but driving the output enable of a 74LS374.   I think it would be possible to do something similar (with less lines) using the new output header.
Title: Re: USB IR Toy update
Post by: rsdio on July 11, 2010, 11:49:12 pm
[quote author="rct"]I went back and looked at the Nirvis Slink-e (http://http://nirvis.com/schemati2_0.htm) to see how it had 8 IR outputs with a PIC 16C67.  It looks like it is using a single PWM line but driving the output enable of a 74LS374.   I think it would be possible to do something similar (with less lines) using the new output header.[/quote]
Yes, the new output header would allow experimentation along these lines.

As an aside, the 74LS374 only handles 24 mA (2.6 mA when hi), so another chip is needed to boost the current.  With the right transistor, you could take the single line from the IR Toy header and directly drive 8 IR LEDs on one node, and save yourself from the real estate of two 18 to 20 pin chips.  The IR Toy has already been redesigned with a different FET to handle more current, and you could select yet another FET with even more power.  If you hit the limit, then you can double up - instead of 8 IR LEDs on one FET, you could do 4 on each of two, etc.  Just be sure to give each IR LED its own current-limiting resistor, and it should be fine to share all the current on one transistor.
Title: Re: USB IR Toy update
Post by: rct on July 12, 2010, 05:14:13 am
[quote author="rsdio"]
As an aside, the 74LS374 only handles 24 mA (2.6 mA when hi), so another chip is needed to boost the current.
[/quote]

Yes the Slink-e (schematic) (http://http://nirvis.com/schemati2_0.htm) used a TD 62083 8 channel darlington sink driver (datasheet) (http://http://www.semicon.toshiba.co.jp/docs/datasheet/en/LinearIC/TD62083AFG_TD62084APG_en_datasheet_091001.pdf) to provide enough current for the 8 leds.  It draws power off the +9V supply to the box.
Title: Re: USB IR Toy update
Post by: rsdio on July 12, 2010, 08:11:12 am
Thanks for the part number - it was too small to read in the GIF of the schematic.

My point is that you can replace both chips with a transistor or two, saving a lot of board space and money, not to mention passive current losses.  But you probably do have to pay attention to duty cycle and other things.
Title: Re: USB IR Toy update
Post by: rct on July 12, 2010, 04:02:54 pm
[quote author="rsdio"]
My point is that you can replace both chips with a transistor or two, saving a lot of board space and money, not to mention passive current losses.  But you probably do have to pay attention to duty cycle and other things.
[/quote]

I understand your point with regards to using a FET to replace the darlington array.  However I don't see how a transistor or two would let me control 8 IR LED (zones) independently.  In case it's it's not clear I'm looking for the capability to to send IR output to a specific zone, excluding the others.    

FWIW, My current use case for the Slink-e is I have 3 of its IR outputs going to 3 different rooms remotely controlling 3 different air conditioners (mitsubishi mr. slim).   They all use the same IR code set, no addressing as far as I've been able to find).   Note: The slink-e isn't being made any more, and I'll need to replace it at some point.   

One of the attractive things about the USB IR Toy is the price point., so I suppose I could also solve the problem by just buying multiple USB IR Toys, but there wouldn't be much learning involved in that.

I think there is another benefit the slink-e gets from using the 74l374, it has tri-state outputs.  I'm pretty sure (but need to test it) that the LEDs are completely off when not in use (Output enable not set).
Title: Re: USB IR Toy update
Post by: rsdio on July 12, 2010, 09:51:05 pm
[quote author="rct"]I understand your point with regards to using a FET to replace the darlington array.  However I don't see how a transistor or two would let me control 8 IR LED (zones) independently.  In case it's it's not clear I'm looking for the capability to to send IR output to a specific zone, excluding the others.    

FWIW, My current use case for the Slink-e is I have 3 of its IR outputs going to 3 different rooms remotely controlling 3 different air conditioners (mitsubishi mr. slim).   They all use the same IR code set, no addressing as far as I've been able to find).   Note: The slink-e isn't being made any more, and I'll need to replace it at some point.[/quote]That sounds like a cool project.  Yes, your requirements call for something different than just 8 duplicated outputs, which I assumed someone would want for extra power and distance.

In your case, it might be difficult to drive all 3 rooms with different commands at the exact same instant, but you could control one LED at a time.  If you built a circuit where some of the unused PIC pins provide a select address, then a decoder chip and current boost would work.  Depending upon your budget, you could use the 8-channel chips, or just stick to exactly 3 circuits.  Maybe a 2-to-4 decoder with 3 transistors.
Title: Remote-controlling similar devices in different rooms: application for RF header
Post by: TEN on July 15, 2010, 07:55:44 am
This is where my proposal of using the I/O header to connect RF modules (cheap from eBay etc.) directly to the USB Toy (using baseband OOK without IR carrier modulation for these) comes into play:

In most jurisdictions, there are some 2 or 3 ISM bands available, each with a number of channels and allowing various modulations - so one would need a fairly huge mansion to run out of different RF transmitters/transceivers to cover each room with its own wireless IR extender (e.g. something like http://www.airwave.com.tw/IR-Extender.html (http://www.airwave.com.tw/IR-Extender.html) or http://www.marmitek.com/en/catalogus/pr ... roduct=220 (http://www.marmitek.com/en/catalogus/product.php?subgroep=3&product=220) - fitted with another RF receiver module if need be) - or on some devices, directly fit a module to feed in the RF receiver output where they'd expect the demodulated IR.
Title: Re: USB IR Toy update
Post by: ian on August 02, 2010, 01:24:25 pm
Sorry I didn't update this sooner. Here's the first prototype boards.

Changes from previous version:
1. IR RX to header
2. IR TX to header
3. Flipped ICSP header
4. Frequency counter connected to INT1 for alternate interrupt type

This will probably be incremented to v2 because of the new hardware features. The new 'v' command in firmware v1.05+ will report, for example, v205.

We'd really like to release this hardware as BY-SA, but the USB stack (microchip) and VID/PID sub-license make it a bit hairy. We haven't decided what to do yet.
Title: Re: USB IR Toy update
Post by: rsdio on August 03, 2010, 07:47:00 am
[quote author="ian"]We'd really like to release this hardware as BY-SA,[/quote]What is BY-SA?
Quote
but the USB stack (microchip) and VID/PID sub-license make it a bit hairy. We haven't decided what to do yet.
I cannot say what would work for everyone else, but I would be perfectly happy to compile the firmware myself, using the Microchip USB Stack sources that I already have obtained on my own, and Flash the firmware with a PICkit 2 with ICSP.

I realize that I might be in the minority, though, since most people might not want to mess around with MPLAB, etc.  But I thought I would put it out there as an example of what would be acceptable to me, at least.  Is it worth putting up a poll?  Can we even do polls on this forum?
Title: Re: USB IR Toy update
Post by: ian on August 03, 2010, 08:37:27 am
Creative commons Attribution Share-Alike, it was the same with a non-commercial clause because of the agreements we signed for the USB VID/PID and USB stack.

I think you are among the <1% of users who would be able to compile and program the firmware yourself. This forum does polls, there's a new poll button next to the new topic button.
Title: Re: USB IR Toy update
Post by: liyin on August 03, 2010, 05:09:44 pm
Maybe you can post a "How to" on the compilation of the Microchip USB stack, or just show any modifications to the sources.
Title: Re: USB IR Toy update
Post by: ian on August 11, 2010, 11:32:54 am
The postman brought these boards (pic), and some others.
Title: Re: USB IR Toy update
Post by: ian on August 12, 2010, 04:56:28 pm
Assembled and tested, front and back pictures attached. I really like the key on the back, super classy.

Don;t have the IR detector yet, will get it in a few days and write supporting firmware.
Title: Re: USB IR Toy update
Post by: ian on August 23, 2010, 02:51:30 pm
With IR frequency detector. I'm going to add the new transmit mode and support for frequency measurement today.
Title: Re: USB IR Toy update
Post by: ian on August 23, 2010, 10:04:24 pm
Frequency measurement works ok, but you have to be really close for a good measurement. I've heard this about other similar designs too. A spreadsheet of measurements is attached.

Here are the firmware changes for the update:
*Version detect using IR detector pullup, universal binary for all hardware versions
*Measure us from first rising edge of IR modulated waveform (raw) to second rising edge (period x2)
*Count total raw IR waveform ticks for a whole sample period

New command 0x04 returns the period*2 measurement and the tick count.
Title: Re: USB IR Toy update
Post by: rsdio on August 24, 2010, 01:34:07 am
[quote author="ian"]
*Measure us from first rising edge of IR modulated waveform (raw) to second rising edge (period x2)
*Count total raw IR waveform ticks for a whole sample period

New command 0x04 returns the period*2 measurement and the tick count.
[/quote]Cool stuff!

But I don't understand why rising edge to rising edge would be period x2.  Seems like that would be period x1.  Could you explain?

P.S.  I like the hardware revision auto-detect ... nifty!  Is there any chance that the floating input on rev1 could read as high despite the lack of an external pull-up?  I've had circuits work for a number of revisions until I had to specifically add a pull-down to guarantee that initial logic states were always known.
Title: Re: USB IR Toy update
Post by: ian on August 24, 2010, 08:37:56 am
Quote
But I don't understand why rising edge to rising edge would be period x2.  Seems like that would be period x1.  Could you explain?

I'm probably wrong :) I finished code and posted results really late, I'll pick it up today and figure out what stupid mistakes I made :)

Quote
P.S.  I like the hardware revision auto-detect ... nifty!  Is there any chance that the floating input on rev1 could read as high despite the lack of an external pull-up?  I've had circuits work for a number of revisions until I had to specifically add a pull-down to guarantee that initial logic states were always known.

I have also had this concern, but in practice it works ok. They key is to loop 20+ times and test for the low pin. A floating pin will probably oscillate a bit, but it will most likely hit ground at some point during 20 reads. The same trick was used in the BUs Pirate bootloader v2.
Title: Re: USB IR Toy update
Post by: ian on August 24, 2010, 11:57:22 am
I was wrong. I thought the special event trigger reset the capture timer, but you need to get the values and subtract to find the actual tick count. I always started on the second interrupt because I though it would have 0 interrupt latency, that's why my times were double what I expected.

The new 0x04 command is this:
H/L - start PIC timer count second rising edge of signal
H/L - PIC timer count third rising edge
H/L - PIC timer count fourth rising edge
H/L - total infrared modulated signal light pulses since last 0xff 0xff (will roll over at 0xffff)

Quote
{00}{F4}{02}{43}{03}{91}{01}{B3}

0x00f4 - start timer count
0x0243 - timer count 1
0x0391 - timer count 2
0x01b3 - total infrared modulated light pulses

PIC timer Period 1 count = 0x0243-0x00f4=0x14F (334)
PIC timer Period 2 count = 0x14E (333)
Total infrared pulse count = 0x01b3 = 435

The PIC has a 12MHz internal clock signal, so the actual time is:

(1/12000000)* PIC timer count = (1/12000000)*334 = 0.0000278333 = +0.20% of the 0.0000277778 actual 36KHz period.

Much better than before, thanks for the note rsdio. Updated test spreadsheet attached.
Title: Re: USB IR Toy update
Post by: ian on November 01, 2010, 06:51:36 pm
Here's another test I tried, not sure which to use. This design uses three LEDs. Two 50degree wide-angle LEDs on the side, and a 25 degree narrow beam LED in the center. Total current in 100mA, could be pushed to 200mA. Using 3 LEDs reduced the wattage of the current limiting resistor required.
Title: Re: USB IR Toy update
Post by: rsdio on November 01, 2010, 09:39:06 pm
Stacking the LEDs to reduce the resistance makes sense, but how do you fit 3 into 5 V?
I guess the SFH 480 is about 1.2 V at 100 mA, or three would be 3.6 V.
But the SFH 480 will handle 1 A with a 2.5 Vf and 2.5 A with a 3.4 Vf.
Seems like you could get more brightness with a single IR LED if you just boost the current high enough, rather than running 3 of them at a small fraction.  You would need a hefty capacitor to burst more than 500 mA on the USB IR Toy.
Caveat: I haven't tried this.