Yes, if you use a module, then for every burst of 40KHz it will output a negative pulse. At that level, you only need to convert the 14 bit packet into a command.

What I would like to do is only use an infrared photo sensor, and have to actually listen for the carrier wave and also decode the raw data.

If you want to use a simpler infrared photo sensor, perhaps a large pullup, can create a simple monostable action so the carrier is filtered ?

However, the receiver modules are simple, and have good immunity to lighting etc, so they will be hard to beat.

Brad is the one that has tried it, So I'll let him confirm if the baseband signal sharing a pin with the audio is a problem, but I imagine it would be.

Issues like that are why I think a move to a 14 pin package makes much more sense.

Then the software can have fewer self-imposed compromises, and a better performance results - and it's cheaper as a bonus :)

andrewm1973 wrote:

RC5 is something like manchester with a one or two kilohert baud rate from memory. That would mean there would be a 1khz and a 500hz signal appearing there when buttons are pressed.

WRT just trying to AM demodulate (no bandpassing) the 38Khz with a large R (or RC), that would still have the baseband noise and loose the ambient light immunity of the 38Khz signal (its reason for existing)

Yes, the simple 'infrared photo sensor' likely needs some added bandpass configure and amplifier for those ambient and lighting rejection reasons, which is why I think the receiver modules are actually simpler to deploy.

It would change the game going up to a SOIC14. Then you COULD have a chip with 2K or RAM. I don't think that is Brads game and he gets his fun by trying to squeeze it into the 8 pin chip with 512B RAM.

It would change the game going up to a SOIC14. Then you COULD have a chip with 2K or RAM. I don't think that is Brads game and he gets his fun by trying to squeeze it into the 8 pin chip with 512B RAM.

The bigger challenge is to squeeze the operations into the code, The package limit delivers a predictable outcome, that limits what the software can deliver - even on 512 bytes RAM.

It would change the game going up to a SOIC14. Then you COULD have a chip with 2K or RAM. I don't think that is Brads game and he gets his fun by trying to squeeze it into the 8 pin chip with 512B RAM.

The bigger challenge is to squeeze the operations into the code, The package limit delivers a predictable outcome, that limits what the software can deliver - even on 512 bytes RAM.

(There are 10 pin MCUs, just not very many of them...)

No I think the bigger challenge is to get as much functionality out of 8 pins.

Impressive VGA demos on AVRs have been around for a decade (look at Craft by lft).

Large sprites have been around on AVR video things for quite some time (look at Brads own demo that had a horse running in it)

Squeezing insane amounts of action out of the available clock cycles has been done (look at my project T2K)

What brad has done here that is _amazing_ is getting more functionality from 8 pins than at first you would think is possible.

I'm pretty sure he wants to stay on 8 pins.

I would really like to see him be able to get that IR decoding working on 8 pins and will offer any suggestions and help I can to see him achieve it.

@brad - PB4 is an ADC pin. You could modulate the voltage on that between 5v and some other high voltage that is well above the sync "low threshold" at the RC5 baseband rate and still get data at non-sync times.

You would go blind during sync. But IR remotes transmit each button press over and over, so you should be able to get a good read in there somewhere.

Edit: Ignore what I said about going blind during sync and that being a problem. I just looked up the VSync period on VGA - it is only 2 H_periods or 1/15000s period. That is and order of magnitude less than a bit time in the manchester RC5 stream.

It should be trivial to put a 38Khz IR receiver module (GP1UX or something) shared with the Sync pin (PB4) and get the baseband manchester with the ADC.

For a 3rd attempt, I am allowing myself the use of a transistor (per pin) somehow.

This is fair game since I already have one to amplify sound, and it won't be required.

Perhaps some kind of 3 input NAND gate.

Sync (Red) only pulls lo if all 3 color bits are hi.

Somehow this also blocks output of color, as this would cause an image failure.

Such a scheme would loose one color, but to win, I could go from 8 colors to 7.

I am looking at other ideas as well.

Maybe there is some kind of ultra fast switching 4.4 zener that won't leave image gosting.

Brad

andrewm1973 wrote:

@brad - PB4 is an ADC pin. You could modulate the voltage on that between 5v and some other high voltage that is well above the sync "low threshold" at the RC5 baseband rate and still get data at non-sync times.

You would go blind during sync. But IR remotes transmit each button press over and over, so you should be able to get a good read in there somewhere.

Edit: Ignore what I said about going blind during sync and that being a problem. I just looked up the VSync period on VGA - it is only 2 H_periods or 1/15000s period. That is and order of magnitude less than a bit time in the manchester RC5 stream.

It should be trivial to put a 38Khz IR receiver module (GP1UX or something) shared with the Sync pin (PB4) and get the baseband manchester with the ADC.