remote power control of your rig

[djacobow]

So, as I further pursue controlling my HF rig from afar (mostly, from work), I've to the conclusion that I really want to be able to remotely shut it down. I haven't had any stuck key issues yet, but computers and networks being what they are, I think it's inevitable.

I've decided to design a power controller that I can control remotely. It will be controlled via i2c from the same Raspberry Pi that serves as my network node for forwarding audio and serial. My plan is to put a small micro on the controller that will take commands from the RPi, but also have a watchdog, and if it isn't pinged before a certain timeout, the it powers everything down.

I want to switch DC to the rig and some peripherals, and also have a separate AC channel or two. I've done AC switches before, fully optoisolated with triac drivers, and that works fine.

I've got two design choices in front of me for the DC switching that I'm not sure which way to go.

I want to use FETs to switch rather than relays. Do I go for low side switching, or high side switching with P devices, or high side with some kind of charge pumpy driver chip and N devices? I think I'd prefer to high switch the high side, all else equal, but I'm not sure I have a strong justification. Also, the reasonably priced P FETs I'm seeing that can switch 30A or so have Rdson in the range of 0.040 ohms. Even two in parallel will dissipate on the order of 9W each @30A. Ugh. Big heat sink, fan, etc. It's on the order of not being practical. (Not that I really pull 30A continuously very often, but in theory...)

The second question, related to the first, is whether I want the DC switching isolated from the power to the controller itself. RPi and controller will be powered by a wall wart. I can have a common ground (really, negative) with my rig PSU, and that makes it easy to do a few nice things like maybe power the controller from the rig PSU instead, or monitor the voltage output and relay that back through the micro. Alternatively, I could have totally isolated power/gnd for the device and power/gnd for the rig, with a 4N25 type of device in the first stage of the FET driver. Is there any advantage to the isolation? Maybe it's not worth the trouble.

Curious to know people's thoughts.

[NA5WH]

N-channel fets are a much easier to drive by micros, but p-channel can be done with the use of a npn transistor, no need for charge pumps... just a couple of resistors and an npn to drive the gate. Only potential downside to p-channel, is if your controller fails, it may stay on the "on" state.

[djacobow]

Thanks for the response. I have a PCB out for fab that is based on P devices switching the high side.

I don't think low-side switching would work since some / most / all ham gear bonds "earth" ground connection and negative power supply internally. So if you "open" the negative, you still get a current path through the equipment all grounded together.

I found P FETs for less than $2 each which have an Rdson < 0.04 ohm and can handle up to 30V Vds and >30A Id. I think I can live with that for the current I'm switching 30A @ 13.8V. I'll be paralleling two for extra current margin. I'd like more than 2x voltage margin, but maybe these will work. I also kept the distance between transistors and connectors very short and the traces are huge polygons, so hopefully current on the board won't be an issue.

I'm doing as you suggest, driving with an NPN pull down the gate, and a resistor pulling up. The resistor is tied to the same 12V rail as the FET, so hopefully if the npn transistor fails, the gate will go high and switch the FET off. We'll see.

Anyway, I'll disappear while I wait for my boards and then report back on how it works out!

[NA5WH]

Sorry for the late reply (still getting used to the notifications on this forum).  Yeah, I agree, I tend to like having all my radio gear negatives at ground, so yeah, I agree P-channel does make sense, even if it cant be run directly off a micro.

I've found most fets can be run up to their specs, but no much further, so I think 2x  of the fets you've suggested will likely be fine. There are some nice power-fets that can take far more, but probably over-kill for this application.

It all depends on the failure mode. Realistically, though, the chance of it failing and your rig key-down failing at the same time, pretty hard. 

Only other thing you might look at once you have it built up is just double check with a scope there is no oscillation anywhere.. both for your rig as well as the fet's heat load.  I had a radio that put enough noise back down the power supply lines to mess up a switching power supply transistor.

But would love to see the final product... I have a desire to setup a remove rig somewhere I can actually have an antenna, and also not be surrounded with stucco houses that are wrapped in metal foil... would be nice to have a complete solution for remote operations.

[djacobow]

So, my first boards came back with some horrible mistakes, due to me mixing a PFET schematic symbol with an NFET footprint. My second board requires a bodge or two, as well, and I want to move the mounting holes and some other components, but basically, the thing works as I intended.

The board itself is basically designed as an Arduino that just so happens to control a big switch attached to Anderson Power Poles. In addition to the DC control, there is an optoisolated triac for an AC device, and a couple of LEDs you can switch. The DC is fused with a 30A ATO fuse and the AC is fused as well. The unit also records the 12V voltage. There is a normal, ridiculous, Arduino header set, as well as a special header to match a Raspberry Pi. There is also a 5V regulator so that you can power the Ard (and optionally, the Pi) from the DC input, but you can also jumper select to program the Ard from the Pi. (This is useful if you intend to use the AC output to turn the 12V PSU off).

Communication with the RPi is over the i2c pins, but there are jumpers for using serial or the Ard's SPI pins, too. It should even be possible to program the Ard in-circuit from the RPi, though I have not tried that yet. Over the i2c pins, I decided, for fun, not to use i2c, but to bit bang my own little protocol. It seems to work OK, but I might switch over to i2c which may be faster.

The RPi is running Raspbian Jesse. There is a server running in Python, which communicates with the Ard and which hosts a webpage and a few endpoints to collect system status and to change registers. You open the webpage at your remote location. Browser periodically does a background XmlHttpRequest to the Rpi server and if the watchdog is nearing timeout, it resets it. There are other options, but the basic idea is that in normal operation, as long as your Internet connection to the RPi is good, the device will keep getting pings and will stay up. If something goes wrong, your POSTS to the RPi will stop getting through, and eventually the Ard watchdog will time out and clear any unmasked output bits. Similarly, if the RPi loses internet or crashes, the Ard will eventually time out and shut down.

Lots of work still to do, but it is in a usable state for my purposes. I had fantasies of making this into a kit, but I see that the polish to get there is a lot of effort. Also, I have no idea if anyone else wants something like this.

[djacobow]

Though there doesn't seem to be enough interest to justify writing much more documentation on this project or offering it as a kit, I have put the design files up on github:

https://github.com/djacobow/rigminder2

Best,
Dave J