What are the chances...

[vttom]

...that Rev Ed would consider changing the infrain2 command so that it will accept IR codes from non-TV device codes?

The reason I ask is because I'm working on a project where I'd like to use infrain2 to capture Sony IR Remote codes for a Sony A/V receiver (amplifier) rather than a Sony TV.

Ideally, it would be nice if you could pass infrain2 a value which corresponds to the device ID that you want to receive. For backward compatibility, make the device ID argument optional, so if you don't supply one it, it will continue to work exactly as it does now.

 

[hippy]

What's the chance ...

Did you delete the part about gold bullion and riches beyond Rev-Ed's wildest dreams ?

It likely wouldn't be possible to update current firmware but it's something that could possibly be done for future PICAXE so I've made a note of it and I'm sure the suggestion will be considered.

It is possible to bit-bang in Sony IR ( it's a quite slow protocol ) so it should be possible to bit-bang in the full device and commands stream then check the whole lot or just match device code.

 

[inglewoodpete]

Stay tuned. I'm developing code for a 20X2 to handle 32 bit NEC-format IR commands as a background task (via interrupts).

Famous last words: it should be available in a couple of weeks.

Peter

 

[vttom]

I got to thinking about this again and realized I could use a series of pulsin commands to measure the lengths of the pulses (In the SIRC protocol, 1's are long pulses, 0's are short pulses).

The difficulty is that I wanted to use a small PICAXE like the 08M or 14M which only has 7 word variables, and they're only fast enough to capture the pulses if I call the pulsins back-to-back without any other code in-between.

My Eurika moment was when I realized I could get different parts of the data from different repeats of the IR code (presumably the codes are never sent just once).

Here's the result:

' 4MHz just won't cut it
setfreq m8

' Init vars
b0=0
b1=1

' Wait for AGC Pulse
do
  pulsin 3,0,w1
loop until w1 > 400

' Skip to the repeated code
pause 60

' Get 1st 6 bits
pulsin 3,0,w1 ' AGC (discarded)
pulsin 3,0,w1 ' cmd[0]
pulsin 3,0,w2 ' cmd[1]
pulsin 3,0,w3 ' cmd[2]
pulsin 3,0,w4 ' cmd[3]
pulsin 3,0,w5 ' cmd[4]
pulsin 3,0,w6 ' cmd[5]

bit0=b3
bit1=b5
bit2=b7
bit3=b9
bit4=b11
bit5=b13

' Skip to next repeated code
pause 60

' Get 2nd 6 bits
pulsin 3,0,w1 ' AGC    (discarded)
pulsin 3,0,w1 ' cmd[0] (discarded)
pulsin 3,0,w1 ' cmd[1] (discarded)
pulsin 3,0,w1 ' cmd[2] (discarded)
pulsin 3,0,w1 ' cmd[3] (discarded)
pulsin 3,0,w1 ' cmd[4] (discarded)
pulsin 3,0,w1 ' cmd[5] (discarded)
pulsin 3,0,w1 ' cmd[6]
pulsin 3,0,w2 ' id[0]
pulsin 3,0,w3 ' id[1]
pulsin 3,0,w4 ' id[2]
pulsin 3,0,w5 ' id[3]
pulsin 3,0,w6 ' id[4]

bit6=b3
bit8=b5
bit9=b7
bit10=b9
bit11=b11
bit12=b13

' At this point...
' b0 contains command code and
' b1 contains id code

Note that I use a major cheat here. I discovered that the short pulses give me a pulsin value < 255 while the long pulses give me a pulsin value > 255. That means I can use the LSBit of the MSByte of the word var as the data without any other manipulations.

 

[vttom]

Oh, and here's a slightly-optimized version which saves me 7 calls to pulsin at the cost of 2 gosubs and 1 return...

' 4MHz just won't cut it
setfreq m8

' Init vars
b0=0
b1=1

' Wait for AGC Pulse
do
  pulsin 3,0,w1
loop until w1 > 400

' Skip to the repeated code
pause 60

' Get 1st 6 bits
gosub getit0

bit0=b3
bit1=b5
bit2=b7
bit3=b9
bit4=b11
bit5=b13

' Skip to next repeated code
pause 60

' Get 2nd 6 bits
gosub getit1

bit6=b3
bit8=b5
bit9=b7
bit10=b9
bit11=b11
bit12=b13

' At this point...
' b0 contains command code and
' b1 contains id code

end

getit1: pulsin 3,0,w1 '         AGC
        pulsin 3,0,w1 '         cmd[0]
        pulsin 3,0,w1 '         cmd[1]
        pulsin 3,0,w1 '         cmd[2]
        pulsin 3,0,w1 '         cmd[3]
        pulsin 3,0,w1 '         cmd[4]
getit0: pulsin 3,0,w1 ' AGC     cmd[5]
        pulsin 3,0,w1 ' cmd[0]  cmd[6]
        pulsin 3,0,w2 ' cmd[1]  id[0]
        pulsin 3,0,w3 ' cmd[2]  id[1]
        pulsin 3,0,w4 ' cmd[3]  id[2]
        pulsin 3,0,w5 ' cmd[4]  id[3]
        pulsin 3,0,w6 ' cmd[5]  id[4]

	return

 

[hippy]

pulsin 3,0,w1 ' cmd[0]
bit0=b3

I'm not too sure how reliable that will be because you are setting bit0 to the lsb value in w1; a slight timing shift could mean disaster. Ideally you want 'bit0=w1/K Max 1' where K is whatever it takes to distinguish the "1" or "0" pulse.

Another possibility for handling all received bits in one go; perhaps slow the PICAXE down so pulse length readings are half ( or less ) than they usually are, so they fit into a byte.

 

[vttom]

pulsin 3,0,w1 ' cmd[0]
bit0=b3

I'm not too sure how reliable that will be because you are setting bit0 to the lsb value in w1; a slight timing shift could mean disaster. Ideally you want 'bit0=w1/K Max 1' where K is whatever it takes to distinguish the "1" or "0" pulse.

Well, so far it works as-is. But I may make a change like this if I find I need to for reliability.

Another possibility for handling all received bits in one go; perhaps slow the PICAXE down so pulse length readings are half ( or less ) than they usually are, so they fit into a byte.

Yeah, I gave that a try. Unfortunately, at 4MHz I got erratic behavior because it was on the hairy edge of hitting the 600us window between low-going pulses that I'm trying to measure.