New air-con, part 5

After the fiasco of the previous air-con install, I was pleased with the new one, as you can see, and especially that I can make my WiFi controllers.

However, this month, as we have got warmer, I have run in to an issue. It was gradual, kicking in some afternoons. Initially it was something that fooled my temperature control, causing it to flip to heating and back to cooling...

I made the controller a bit more reactive, and fixed the flipping to heating, which was good, but still, in the afternoons, things were not right.

Will all this, over night was OK, mostly, but not always. After a while I realised the clue was in the power traces. Basically, after a while the unit switches in to a mode where it cycles, around 11 minutes on, and 11 minutes off, and a low fan when off too.

This is not enough to keep my office cool, and as we go on, it is getting worse and worse. It always starts the day OK for some minutes, but can go in to this mode right away after that.

This is crazy. I tried all sorts. I thought maybe it is the "econo" mode, which apparent limits cooling when below a certain temperature. I even fudged the temperature (replacing thermistor with a resistor) to test this, but no joy.

After a lot of testing for a couple of weeks, I have found it. It is an "anti freeze" mode. This is what they say (when you know what to google). Needless to say that Daikin support did not work this out for us.

What is especially annoying is that when it is pending 10 minutes with "thermostat off", it also puts the fan in what is shows as "LL" mode, i.e. slower than "L". Well, if it want to avoid the coil freezing you would think it should keep the fan at "H", but that is not what happens.

So now we know what it is, well what can I do?

For a start, I can try and pre-empt the anti-freeze logic, but that does not really solve the problem of why it is freezing the first place. It would have helped a lot if Daikin could have simply said "that looks like anti-freeze kicking in" when asked. Indeed, a fault/indicator on the controller or controller app would have helped so we knew the problem.

Even so, a way better outcome than previous air-con install, and some hope it will be "just working" soon.

Update: Clearly air-flow is the issue, but by preempting the anti-freeze I can keep it on full fan more and so have a slightly improved performance for now.

Part 6

Not using solder paste?

I made the mistake of ordering a board and not ordering the solder paste stencil.

So what to do - well, not a complex board, I tinned the pads and applied some flux as it is a bit sticky...

Then I applied the components. Now this is where I wish I had applied less solder to make it flatter as they did not stay put very well.

Getting flux on the tweezers was also an issue, so lots of cleaning.

Then I cooked in the oven the same as if I had solder paste.

To my utter amazement, it worked perfectly. I did put in a sonic cleaner, which did not help much in cleaning it up...

However, a nylon brush and some IPA, and bingo..

But the damn board works!

So there you have it - an option when you have no stencil!

DHCPv6

First off, an apology! FireBrick and A&A have been pioneers in making IPv6 work in practice in the UK. The current FireBrick operating system has been designed with IPv6 from the start, and not as an afterthought. This means that at every stage the notion of an IP address comes with the notion of "which sort of IP address". We are proud of that. But we have been lax in one notable area - DHCPv6. Sorry.

The problem is that IPv6 has a mechanism, SLAAC, which assigns an IP address on Ethernet. It is very simple, and works. The router sends out some details (which can include DNS servers, etc, as well), and allows devices to pick an address. With 64 bits of local address, this is easy to do in a way that avoids any collisions. Indeed, devices often pick lots of addresses, cycling them quickly, to hide how many devices you have on a subnet, etc. (privacy addressing). It works well, and in the UK it was pretty much the only thing being used.

DHCPv6 is a "stateful" way to manage addresses, and like DHCP (for IPv4) it has a lot of options. Thankfully IPv4 DCHP has been around a long time, and the sane options to implement are clear. The FireBrick IPv4 DHCP server is actually pretty flexible and powerful and works well.

But DHPCv6 is newer, and has a lot of options. One of the big ones is "prefix delegation" - telling a device it has one or more blocks of IP addresses to use on its interfaces to give out to devices it has connected. This is just one of the complications for a DHCPv6 server on Ethernet - it has to consider not only allocating and tracking an IP address, but a block of IP addresses and routing. As a client we also have to consider if we want to ask for a block of IP addresses and what interfaces we can use to assign those IP addresses.

We do this already, but we only do it for the LNS/PPPoE (broadband) side of things. We work as a server when operating as an LNS, linking to RADIUS and routing. We work as a client when PPPoE, allocating a dynamic block of prefix delegated IPs to the LAN interface. So we have a lot of the tools already.

Until now we did have an option on our router announcements on IPv6 over Ethernet to allow a DHCPv6 server, and even an option for that to be the FireBrick itself. The idea was the FireBrick would issue an address the same as SLAAC. This was specifically to allow for devices that only worked using DHCPv6. But we really did not find any such devices. Devices (like the FireBrick itself) that only handle SLAAC are actually more common from what we can see.

But the time has come for DHCPv6. And there will be several alpha releases around this. We need to take careful steps to integrate the code which currently only works for LNS and PPPoE to be used for Ethernet. We need to decide on the config for this, and the options we offer. This will not be simple.

So, watch this space. It will take a while as we are working hard on the new 10G FB9000 router right now, but we are starting. We already have an alpha which does a consistent simple IPv6 address allocation over DHCPv6 on Ethernet (a hash based address to avoid giving out the MAC). We hope next to have DHCPv6 client over Ethernet and then DHCPv6 client prefix delegation. The server side will be a lot more work considering the config, and how much we link with IPv4 config, so bear with us.