Tri-amping

For the New Lab, I thought it would be a good time to improve the sound system a bit. I have a pair of Kef Concerto speakers from the 70s, I have the power amp boards from the project a couple of years ago, I have a donor home cinema amp or two so some bits come together.

I was sorting out someone's lousy sounding hi-fi on Hayling last year or so, where they said the sound was muffled. It turned out that their speakers were bi-amp capable, and they were only driving the bass part. I'd wired them in properly, and that thought was in the back of my mind. I liked the sound of those bi-amped speakers, and it stuck with me. I did some research online, found that there were people who did recommend tri-amping as well as bi-amping for smaller bookshelf-y sized speakers, so I was ready for it.

Then an offer from Seeed studios dropped in the mail box for 5 10cm square boards for about a tenner including postage, so I went for it.

This is the Linkwitz filter - two required, one for each channel. The idea is that it is fed from a regular 700mV kind of level output from a pre-amp or mixer, has some fairly steep active filters that provide the low end, the mid-band and the high end signals to discrete power amplifiers, which are then wired directly to the speaker drive units (maybe with an inline fuse in a vain attempt to save the life of a speaker cone if the amp decides to fail in dramatic fashion).

KiCad .. !

Well, kind of getting used to it. Thought I would design something and do a layout .. so here is the schematic. This is a good ol' PTH (that's Pin Thru Hole for those of you who are not suffering from the effects of age on the eyes, and can use SMT devices without a stereo travelling microscope) design of an MSF Receiver. MSF is the time signal broadcast from the National Physics Lab. now from somewhere in Cumbria at 60KHz. So a simple receiver with an external ferrite rod and MW coil feeds into a simple circuit to recover a digital signal.

.. and here the layout!

It's really good. Functionality is good - of course it is very different to Eagle, and finding ones way around the menus while adopting a new workflow ..  but it performs well, has some really useful features and quite a few bits I like a lot.

Now there are a couple of things I don't like about KiCad, but getting used to them.

1) No curved traces! Really, guys. My signature curvy traces no more?
2) No embedded autorouter. Well, to be honest I can route well enough and quickly enough not to worry me. The push/shove router works very well, and you can buy plug-in autorouters, but I am talking myself out of them at the mo.

I like the decoupling of the component from the footprint used. It makes the schematic more of an abstract representation of the function of the circuit rather than a particular instance - which helps the mind to keep open.

Just in case you were wondering what I do at work ..

The networky bits of the loft ...

I've a couple of switches in the loft - one for the PoE network (including the cameras) and one for the gig e network. This is going to change, but for now ...

Hiding under the header tank for the central heating .. the existing support wasn't quite wide enough for a 19 inch rack, but it has enough room to mount the switches vertically! That's Fireball on the left.

Fireball, gig e switch. PoE switch and patch panel

... and a lovely table for an iMac G3 - it's running a 2007 version of YellowDog Linux right now, on its huge 13.5 GB drive - great though if you need to log into something quickly. It seems to have more or less survived being off for the last 10 years, but flashes over occasionally, and the screen geometry is a little off whack now. Bless her.

iMac G3

Router .. and KiCad

Have bought a DIR-868L from that auction site.

Have finally managed to get DD-WRT installed on it. (it was a bit of a bugger, but eventually found some excellent advice on Dlink Forums which quotes quarkysg and his work, and recommends a workaround. And it works!

This should let me specify a static route on the internal interface, so it knows that for 192.168.4.x traffic, it needs to route via 192.68.10.80, the famed Fireball machine. So far haven't found the time or energy to try installing it in da house. It also has made me re-think the network topology a bit, and to bring forwards the network work in support of the new Laboratory!

.. which currently looks like this ..

On an unrelated topic, have decided to make the switch from Eagle 6 to KiCad, avoiding the strange subscription model for Eagle now that those people at Autodesk have bought the company. It's a journey,

More routing fun

I still have the odd issue with routing. It seems that external phones don't always route both ways to internal phones.  The problem is that the Dlink router can't route to the phones - need a static route. Unfortunately Dlink managed to eliminate the option of putting in a static route where the target is on the internal interface when they did a software upgrade a long time ago ...

There are workarounds for most Dlink boxen, but not the DIR-615L I have. Nor can I load DD-WRT firmware on it,

However, it can be done on a Dlink DIR-868L, like the one I have just bought from that Auction Site. We'll see if that fixes things soon ...

Phones are working .. PoE is on .. and Asterisk and routing

So I have now installed a couple of switches in the loft, and Fireball, the house server is back online. I established two networks - one yellow zone, for the house and the wifi network, and the purple zone with the phones.

I needed a separate network for the phones, since they need to boot from a TFTP server. Some of the Cisco phones, like the 7970 actually won't seem to accept a static IP, so they need a DHCP server that also gives out the address of the TFTP service as well. Now, since the house router doesn't dish out advanced settings like that - a bit Cisco unique -  I have to serve up the phone network DHCP and TFTP settings from Fireball. So it is the router for the phone subnet.

As is commonplace for Asterisk, the phones then started exhibiting the one-way-voice problem. If I call between extensions in the house, no problems. However, as soon as I try to call in from outside, the voice only works one way.

Turns out that it is not the usual codec issue, nor is it a NAT issue, but a routing issue ..

If the traffic is coming from a hard phone to a soft phone, the hard phones are routed to Fireball anyway, since their default gateway is the Fireball 192.168.4.1 interface. However the reverse doesn't work, since the switch is not layer 3, and doesn't know that 192.168.4.x traffic needs to route via Fireball. Since all of the hard phones are on a network that doesn't have a routing rule on the router (not a good name for a device for which I can't provide internal routing information), they can't receive RTP data from POTS calls and the sipgate service.

So I changed the settings in sip.conf to force all traffic for phones to go via Fireball, rather than trying to allow the RTP flows directly between devices. That seems to work. 

sip.conf has to be set to identify each of the internal networks separately. In my case this looks like

externip=hilabs.dlinkddns.com ; This is the free ddns service from Dlink - works fine

localnet=192.168.10.0/24 ; allows multiple lines

localnet=192.168.4.0/24   ; 

directmedia = no ; force all traffic to go via Asterisk on Fireball 

Seems to work ok now. The loading on Fireball increases very slightly, but hardly an issue since the compressed audio only consumes about 64K bits/second, and it is compressed and decompressed at source (viz the phones). Unless I was running a call centre, Fireball can cope. It copes an awful lot better now it is running headless, so it's not running KDE, or Gnome, or any window manager at all. I love the command line!