Picaxe only SIRCS?

Hi, I was wondering if the infrain function on the picaxe is still only capable of working with sircs (Sony IR) codes, or if it can be extended to other codes.

I wanted to create some kind o code repeater, so it would receive IR signals from my Samsung TV, store in an eeprom and repeat (i.e. send the same signal via IR LED directly to my TV)

I know this is doable, but am not sure if the picaxe can do it.

Could anyone tell me if this is possible to do with a picaxe 08m?

Thanks

PICAXE can generate other IR codes by bit-banging and I've succeeded in controlling Sky and Virgin STB's plus Panasonic TV and could probably control most IR that way. Is it possible with an 08M; I'd say "no", I used a 20X2 because the 64MHz speed was needed.

A PICAXE could perhaps monitor IR and and store on-off streams or periods for any IR controller but you need fast sampling and I suspect learning controls actually take the stream, work out what it would be ideally and then reconstruct output from that, not a raw stream. A raw stream would be possible with fast enough sampling and the room to store those samples but that's probably more than a PICAXE is capable of.

The best option IMO is to generate the sent codes from minimal data which minimises storage and use something to trigger the codes, keypad or another ( different protocol ) remote. It's possible to put a PICAXE in a remote and create a dedicated controller for anything IR but then there's the issue of power and conserving power; remotes usually hold 2 x AAA or 2 x AA.

Take a look at -

http://www.picaxeforum.co.uk/showthread.php?t=14747

And latest, probably incomplete, code for what I was playing with is attached.

Thanks for the reply Hippy. it sure is a lot mote complex than I thought though

I was almost expecting it to be and out-of-the-box solution. I do appreciate that it can be done with some bit-banging, however, I was wondering if this would not be facilitated by using any sort of external device (i2c or spi?).

Does anyone here have any knowledge of such device seeing picaxe can't do it easily?

Thanks

Sony's code seems to be the easiest and most reliable one, that's why it (I think) it is chosen for Picaxe ,too. And so many other A/V -manufacturer uses the same code.

Seen before some very bold codes to read tv-remotes through PC-irda!
Successful too, but those codes are masterpieces... since tv-remote's waveform and everything else is VERY different approach than irda.

Sony's SIRC has become a "standard", and therefore the others must be much different (for not to break patents). No wonder, why the bit-bang code for others is complicated.

If I have understood right, there IS chips for other standards, but NOT for sale.The decoder-chips are made for/used only by A/V-manufacturers...

A related thought: many cell-phones now-a-days contain a feature of working as a remote-control... haven't yet myself tried , but will!

Of course, BT would be nicer! (does anyone know, is there a way/chip to get Picaxe recognize a BT-phone?)
If there were (plus password detection) what would be the easiest REMOTE way to open doors etc. : a cellphone in the pocket... no action needed (as with IR / "touch" -keys)

@KTarke,

There are Serial to BT adapters, one example: URL to PDF datasheet

Haven't used it. Only found it in a catalogue.

MPep

MPep said:

@KTarke,

There are Serial to BT adapters, one example: URL to PDF datasheet

Haven't used it. Only found it in a catalogue.

MPep

Click to expand...

Thank You for the tip!
I was about to go to bed, but this prevented it...
Hobby first,sleep later.

I do apologise .

They can be purchased from Digikey, Mouser, etc.

"Universal" IR Receiver

I designed and built a reliable, PICAXE based "universal" IR code receiver a couple of years ago. It works to the 4-byte NEC standard. I currently use it for decoding LG, Topfield, Akai and Grundig IR signals, which all use the NEC standard. With time and patience, it could be adapted to other standards.

The design was published in "Silicon Chip" magazine in August 2008. Silicon Chip has published the bare
IR Receiver Circuit and the Zipped PICAXE Code online.

The code was developed on an 08M and put into service on a 14M. It could easily be adapted to any PICAXE. Note that you would normally use a dedicated PICAXE for the receiver/decoder and feed the data over a serial connection to another PICAXE.

The circuit can be fitted to a very small footprint on stripboard ("veroboard"), which is what I did.

<

Wow, that is quite interesting what you have achieved with the humble 08M. Doing this kind of things with picaxe(time critical code execution) is a real pain in the backside, but it can still be the better option compared to raw programming a microcontroller. Especially, if you have no experience whatsoever in programming microcontrollers with native code, but plenty with picaxe.

That is a nice project and a good use of 08M and hardware assistance to do the job.

Re-reading the opening post, some clarification on what's actually required will help as I had read it as a 'learning remote' style system whereas 'repeater' may simply require extending the range of a remote, may not even require a PICAXE.

For a 'learning remote', what protocol need supporting plays a big part. Some are fast signals and some are not consistent, have CRC, checksum or other bits which toggle on each command sent or when a new button is pushed, some require multiple packets with specific timing to be recognised, some are a command per button, others use commands which carry a combination of buttons ( though that's usually much the same with just one button pushed ).

Non-learning is obviously easier as you only need to generate the right IR bit stream no matter how complicated or how much it changes from one command to the next. My current thinking is one 20X2 ( or other if 64MHz not required ) per single IR protocol bit-banged out. All connected to serial which selects the appropriate 20X2 and tells it which IR command to send. That serial can then be driven by PC or another PICAXE receiving commands from a specific remote, which may actually be a PDA mobile phone, or based on its own PICAXE, can use IR, 433MHz, XBee or anything else. Connect the serial into a Telnet port or some network connected device with serial and you can control your TV etc over the internet, from a browser and so on.

Think of it in this modular way and the system is easy to visualise. Single PICAXE's can handle multiple tasks to save cost and make it more compact if required.

Ok, I think learner was going a bit too far. What I was really trying to accomplish was some sort of pre-set remote.

I like watching TV with certain settings (i.e. saturation, colours, brightness, volume, etc)

Whilst my wife uses different settings.

They don't really change too much, and it would be easy enough to go and change it, but I thought it would be a nice learning project for me to do something like this.

I was thinking about storing the settings in an eeprom, and then only activate them with the click of a button.

It's kinda like a repeater, but the information is stored in memory, and only used once the button is clicked.

Hope this clarifies a bit more.

cheers

That should work. Again I'd see it as only an IR generator being triggered as needed which simplifies things.

The challenge in doing what you want is keeping things in synch. If you have the ability to go to a particular colour setting say all well and good, if you've only got up/down pushes, relative changes, it's more difficult, an open-loop system with no feedback on outcome being correct. You can always wind settings down to zero then back up to where they should be but that's an inconvenience.

Yeah, that's exactly what I thought.. set everything to 0, and then go up the necessary.

Still is this easy to be stored?

Cheers

Depends on definition of "easy" and what you actually have to store. In my example code the commands to send are not actually "stored" as such but constants loaded into variables which are used to determine timing rather than store that timing data itself. I did it that way to minimise storage because there wasn't enough Table or Eeprom memory to hold all that I needed and I didn't want to use I2C Eeprom.