Your learns have the same problem as the one Lars took.  The learn has only 125 bits in it (probably because USB-UIRT has a length limitation) but it should have 128 bits.  I explained above how to take each learn and add the 3 missing bits (3 burst pairs).  

The temperatures are coded so that 20C is  denoted by 0x04, so 18C = 0x02 and 28C is 0x0E.  You can see this in the PDF link in Post #21.  For the American market they approximate 1C = 2F.

Here's your learn, repaired:
0000 006D 0000 0082 007D 003F 0010 0011 0010 0011 0010 0030 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0010 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0011 0010 0010 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0030 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0F92

If you like, I can make a small program that would allow you to use the PDF file to enter any command.  It would take a day or two.

Hello 3FG!

I am experiencing a similar problem to get my Fujitsu ARCON codes (you are already helping me in a post about Sagem DSTIH78 and Sagem RSTIH89 Set Top Box at [Link: remotecentral.com]) and I thank God because you exist!

It would be very helpfull if you could "translate" the PDF file into a program!
Thank you very much for your help.

Best regards,

Marcelo

Hello!

I am facing another problem now.

I copied the command from Post 31 and paste in Pronto Edit NG, then saved the project.
When I opened it again, the command had changed to the following:

0000 006D 0069 0000 007D 003F 0010 0011 0010 0011 0010 0030 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0010 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0011 0010 0011 0010 0030 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0030 0010 0030 0010 0011 0010 0010 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 003F

Note that the last four values have changed from 0F92 to 003F, automatically, and it is missing 3 bits (6 burst pairs).

Does anyone know what is happening?

Thanks
(sorry for my poor English)

Sorry to revive such an old thread, but @dabrams I was wondering, is there any difference in the IR codes transmitted, if your remote control is set to Celsius rather than Fahrenheit? I've been wondering how the Fujitsu remotes deal with this change. I can think of two broad possibilities:

1a) the remote converts Celcius to Fahrenheit and sends the same IR codes as in dabrams' document.

1b) the remote sends Celsius (as Fujitsu = Asia = natively use Celsius) and for people with a Fahrenheit remote, the remote converts internally the selected F value to Celsius in order to decide what IR code to send. (this *could* explain why the remote uses 2-Fahrenheit increments, because this is very roughly equivalent to 1 deg C increments (5/9ths to be precise).

2) The more "implement it properly" option: remote actually sends a different byte (maybe word 7 or word 8) for Celsius remotes than for Fahrenheit remotes.

Any thoughts? I have a celsius Fujitsu remote, but it's a AR-RY3, so I don't know if it even uses the same structure as dabrams' document. I'm quite keen to figure out (and importantly, share) the IR codes on Remote Central, so let me know what I can do to answer the question above. I'm using AnalysIR with an Arduino Uno to do the decoding.

cheers
Ash

Just to reply to myself... so anyone else with a Celsius temperature Fujitsu A/C unit has the answer that I've spent hours testing to figure out.

Firstly, I have tested David's (@dabrams) PDF file against my Fujitsu AR-RY3 remote control, and after initially banging my head against MSB vs LSB etc (first time I've ever decoded pronto codes into bitmapped values), I had a nice spreadsheet with my individual Pronto burst pairs on rows, grouped into bytes, with any bits mapped appropriately etc. Then I just did a bunch of testing to see what Celsius values on the remote control, map to which hex values within Word 9 (Chart A on the PDF). Here are my findings, David I don't know if you feel like updating your PDF or not, but here's the info, "dC" is degrees C shown on my remote, "Bits" is the bits seen in Word 9 bits 4-7, Hex is the hex value, DocSez is what @dabrams' doc listed for that hex value. FYI, other A/C systems in degrees C tend to use the whole available range for that 4-bit value, i.e. 0x0 = 16C, 0x1 = 17C and 0xF = 31C. I can't test if this is the case with Fujitsu since my remote doesn't let me pick those values. The rightmost column FequivC is simply docF converted to Celsius using the real-world conversion rate (C = (F-32)*5/9), I just wanted to show that dC is not just a direct F-to-C conversion, Fujitsu have for the most part simply truncated the decimal part of the equivalent Celsius value, but above 28 degrees that no longer holds true.

dCBitsHexdocFFequivC
301110E8831.11111111
291101D8630
281100C8428.88888889
271011B8227.77777778
261010A8026.66666667
25100197825.55555556
24100087624.44444444
2311177423.33333333
2211067222.22222222
2110157021.11111111
2010046820
191136618.88888889
181026417.77777778

Lastly, one more addition to the PDF should be made: your Fujitsu system doesn't have a Master Mode called HEAT. Mine has Auto, Cool, Dry, Fan and Heat. The PDF lists this for byte 10:

00H = Auto
01H = Cool
02H = Dry
03H = Fan

Mode "Heat" uses 04H.

Hope that's useful info, if anything just to confirm that David's document holds true for my AR-RY3 remote, which I am massively stoked about. It took me a couple of hours to fix up my wrong assumptions (about bit-ordering) and fix my spreadsheet, then magically my values matched his.

Here's a way to use IrScrutinizer to generate signals for Pronto Hex, Global Cache, and a number of other formats.

Add the following entry to IrpProtocols.ini:
[protocol]
name=Fujitsu Aircon
irp={38.4k,413}<1,-1|1,-3>(8,-4,20:8,99:8,0:8,16:8,16:8,254:8,9:8,48:8,H:8,J:8, K:8, L:8, M:8,N:8,32:8,Z:8,1,-104.3m)+ {H=16*A + wOn, J=16*C + B, K=16*E:4 + D:4, L=tOff:8, M=tOff:3:8+fOff*8+16*tOn:4, N=tOn:7:8+128*fOn,Z=256-(H+J+K+L+M+N+80)%256} [A:0..15,wOn:0..1,B:0..15, C:0..15,D:0..15,E:0..15,tOff:0..1024,tOn:0..1024,fOff:0..1,fOn:0..1]

Start IrScrutinizer; on the Export tab, set up the desired format.  For example, to make a signal for GC, select Text as the Export Format. and check sendir.

On the Generate tab, Select Fujitsu AirCon, leave the D, S, and F fields blank, and enter the following example string into the Additional Parameters box:
A=0x07 wOn=1 B=0x04 C=0x02 D=0x03 E=0x03 tOff=53 fOff=0 tOn=0x3 fOn=0x1. This is just an example; you'll need to assemble the correct values from the PDF linked in post #11.

A should be set to the desired value from Table A, etc.  wOn is Word 9 bit 0, tOff is the timer off value in Word 12 and part of Word 13.  fOff is Word 13 bit 3.  tOn is Word 14 and part of Word 13, and fOn is Word 14, bit 7.  IrScrutinizer will compute the checksum.

Click Export on the Generate tab to write e.g. GC sendir.  Clicking the Generate button will put Pronto Hex in the Text box.

Edited to correct typos in the irp.

Kewl! I will add that protocol to next version of the 'Scrutinizer.

Let me just add that when generating signals for exports, there is also the possibility for generating signals for several different parameter values, e.g. by using the asterisk * for parameter value, which will generate signals for all the possible parameter values. (Under the assumption that the export format allows for more than one signal, disallowing e.g. the wave format.) The full list is given here   .
 

Hi 3FG.

Thanks for your post, very helpful, unfortunately I'm still getting stuck :(

I have used irScrutiner with the following options to get

70Deg (21oC) | Mode Cool | Fan Auto

A=0x05 wOn=1 B=0x01 C=0x0 D=0x0 E=0x0 tOff=0 fOff=0 tOn=0x0 fOn=0x0

Which results in the following - however when sending to my Aircon, it dosent respond.

0000 006C 0000 0082 007F 003F 0010 0010 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0FA5


00101000 00010100 14
11000110 01100011 63
00000000 00000000 0
00001000 00010000 10
00001000 00010000 10
01111111 11111110 FE
10010000 00001001 9
00001100 00110000 30
10001010 01010001 51
10000000 00000001 1
00000000 00000000 0
00000000 00000000 0
00000000 00000000 0
00000000 00000000 0
00011100 00111000 38
01111110 01111110 7E

30+51+1+38

120 = C0

I was trying to confirm the check sum is correct following Post 22 and for as far as C0, but I'm not sure how to get "sum x00"

If possible, can you please have a look at this and let me know where I'm going wrong?

Thanks!

Cheers,
Jeremy

EDIT - After reviewing previous posts, I think its related to Word 15 having a value of 38 instead of 20. Attempting to understand why this is the case and how to rectify it.

Yes,
Sorry, I have made two mistakes in the IRP; I'm not sure why.  Anyway, the correct entry to IrpProtocols.ini is (I hope)
[protocol]
name=Fujitsu Aircon
irp={38.4k,413}<1,-1|1,-3>(8,-4,20:8,99:8,0:8,16:8,16:8,254:8,9:8,48:8,H:8,J:8, K:8, L:8, M:8,N:8,32:8,Z:8,1,-104.3m)+ {H=16*A + wOn, J=16*C + B, K=16*E:4 + D:4, L=tOff:8, M=tOff:3:8+fOff*8+16*tOn:4, N=tOn:7:8+128*fOn,Z=256-(H+J+K+L+M+N+80)%256} [A:0..15,wOn:0..1,B:0..15, C:0..15,D:0..15,E:0..15,tOff:0..1024,tOn:0..1024,fOff:0..1,fOn:0..1]

That gives:
0000 006C 0000 0082 007F 003F 0010 0010 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0030 0010 0010 0010 0FA5

One thing to note:  When calculating the checksum, you need to do the arithmetic in hexadecimal, or else convert everything to decimal before adding and then convert back to hexadecimal,

Thanks, I found the 32:8, but couldn't work out the 80 in the checksum.

I had to make a couple more changes to get the aircon to respond, not sure if its model specific or not however -

38.0k,412 and -4 at the end.

So far getting some responses from the AC!! but not for all code changes are working - will keep investigating.

Thanks for the feedback!! :)

[protocol]
name=Fujitsu Aircon2
irp={38.0k,412}<1,-1|1,-3>(8,-4,20:8,99:8,0:8,16:8,16:8,254:8,9:8,48:8,H:8,J:8, K:8, L:8, M:8,N:8,32:8,Z:8,1,-4)+ {H=16*A + wOn, J=16*C + B, K=16*E:4 + D:4, L=tOff:8, M=tOff:3:8+fOff*8+16*tOn:4, N=tOn:7:8+128*fOn,Z=256-(H+J+K+L+M+N+80)%256} [A:0..15,wOn:0..1,B:0..15, C:0..15,D:0..15,E:0..15,tOff:0..1024,tOn:0..1024,fOff:0..1,fOn:0..1]

This IR protocol is presumably Kaseikyo, which is used by many Japanese manfacturers.  The first two bytes of these signals are 20.99, which is Fujitsu's Kaseikyo OEM ID.
So the irp should start {36.7k,432}.  36.7KHz is certainly correct, but the 432 uSec was measured from lots of learns of Kaseikyo signals, and so it may not be quite correct.  Additionally, Pronto Hex and perhaps other formats have trouble getting these durations entirely right, so some experimentation is necessary.  It's difficult to know whether to specify the on duraton as the envelope of the on burst (413) or instead to spec the time as a multiple of the modulation period (432). However, changing from 413 to 412 is really too small a change, so the results are likely to be unstable.  Give a longer time a try.

Thanks so much, 3FG! I tested with your values and was immediately able to make all the commands I tested recognised. Major breakthrough for making the AC codes available, even in LIRC - which now works perfectly for me.

name=Fujitsu_Aircon
irp={36.7k,432}<1,-1|1,-3>(8,-4,20:8,99:8,0:8,16:8,16:8,254:8,9:8,48:8,H:8,J:8, K:8, L:8, M:8,N:8,32:8,Z:8,1,-4)+ \
{H=16*A + wOn, J=16*C + B, K=16*E:4 + D:4, L=tOff:8, M=tOff:3:8+fOff*8+16*tOn:4, N=tOn:7:8+128*fOn,Z=256-(H+J+K+L+M+N+80)%256} \
[A:0..15,wOn:0..1,B:0..15, C:0..15,D:0..15,E:0..15,tOff:0..1024,tOn:0..1024,fOff:0..1,fOn:0..1]

Hi,

I was getting ready to post here with a checksum problem, but in the process of documenting the problem for the forum, I solved it.  I'm still going to post this, as the step by step might help someone else.

I am working with a fujitsu heat pump, and programming in C to send codes to my heat pumps over my network (network connected IR transmitter in each room with a heat pump).

I have been able to capture valid 16 byte commands, and reproduce them. The problem is that I would like to calculate the commands, rather than record every single possible command.

For whatever reason, my bits are reversed from the .pdf in the previous posts (my 1 is a 0 and my 0 is a 1).

Here is a code that works (Cool, Fan High, Swing, 18C):

11010111
00111001
11111111
11110111
11110111
10000000
01101111
11110011
01111011
01111111
01110111
11111111
11111111
11111111
11111011
01000001

And another (Cool, fan high, swing, 20C):

byte#   bin            dec      1=0/0=1     dec          byte reversed
01)     11010111 - 215  - 00101000  -  040
02)     00111001 - 057  - 11000110  -  198
03)     11111111 - 255  - 00000000  -  000
04)     11110111 - 247  - 00001000  -  008
05)     11110111 - 247  - 00001000  -  008
06)     10000000 - 128  - 01111111  -  127
07)     01101111 - 111  - 10010000  -  144
08)     11110011 - 243  - 00001100  -  012  - 00110000  - 48
09)     01111101 - 125  - 10000010  -  130  - 01000001  - 65
10)     01111111 - 127  - 10000000  -  128  - 00000001  - 1
11)     01110111 - 119  - 10001000  -  136  - 00010001  - 17
12)     11111111 - 255  - 00000000  -  000  - 00000000  - 0
13)     11111111 - 255  - 00000000  -  000  - 00000000  - 0
14)     11111111 - 255  - 00000000  -  000  - 00000000  - 0
15)     11111011 - 251  - 00000100  -  004  - 00100000  - 32
16)     01000101 - 069  - 10111010  -  186  - 01011101  - 93

Sum 12 + 130 + 128 + 136 + 4   =  154 (throwing away one overflow)
This sum is not close to 069, 186, or 93.

Sum 48+65+1+17+32 = 163 (256 - 163 = 93!!) Eureka!

Well, there you have another documented calculation of checksum.  I hope it helps someone else.

That sounds great! Would you be willing to share your C program?

On a different note, one of the codes seems to be used for "low noise outdoor unit" on my remote. Any educated guesses on which that could be, or how I find out?

Could someone please send Pronto hex codes for the following. i tried to follow comments, but serious noob

thanks in advance

Economy mode, Quiet fan, cool mode, 27degrees. i am located in australia
Economy mode, Quiet fan, cool mode, 29degrees