Skip to main content ↑ ↓
Topic: USB IR Toy update (Read 17999 times) previous topic - next topic

USB IR Toy update

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.
Got a question? Please ask in the forum for the fastest answers.

Re: USB IR Toy update

Reply #1 –
[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,

Re: USB IR Toy update

Reply #2 –
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).
Got a question? Please ask in the forum for the fastest answers.

Re: USB IR Toy update

Reply #3 –
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)? 

Re: USB IR Toy update

Reply #4 –
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.
Got a question? Please ask in the forum for the fastest answers.

Re: USB IR Toy update

Reply #5 –
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)
Got a question? Please ask in the forum for the fastest answers.

Re: USB IR Toy update

Reply #6 –
Actually, it looks like the CPP IF is set on every edge (image attached).
Got a question? Please ask in the forum for the fastest answers.

Re: USB IR Toy update

Reply #7 –
[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. 

Re: USB IR Toy update

Reply #8 –
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.

Re: USB IR Toy update

Reply #9 –
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).

Re: USB IR Toy update

Reply #10 –
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?

RF, RS232C support?

Reply #11 –
[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.

Re: USB IR Toy update

Reply #12 –
@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.
Got a question? Please ask in the forum for the fastest answers.

Re: USB IR Toy update

Reply #13 –
[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.

Re: USB IR Toy update

Reply #14 –
[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?