Projects

6LoWHAM Research

So, doing some more digging here.  One question people might ask is what kind of applications would I use over this network?

Bear in mind that it’s running at 1200 baud!  If we use HTTP at all, tiny is the word!  No bloated images, and definitely no big heavy JavaScript frameworks like ReactJS, Angular, DoJo or JQuery.  You can forget watching Netflicks in 4k over this link.

HTTP really isn’t designed for low-bandwidth links, as Steve Netting demonstrated:

The page itself is bad enough, but even then, it’s loaded after a minute.  The real slow bit is the 20kB GIF.

So yeah, slow-scan television, the ability to send weather radar images over, that is something I was thinking of, but not like that!

HTTP uses pretty verbose headers:

GET /qld/forecasts/brisbane.shtml?ref=hdr HTTP/1.1
Host: www.bom.gov.au
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-AU,en-GB;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://www.bom.gov.au/products/IDR664.loop.shtml
Cookie: bom_meteye_windspeed_units_knots=yes
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Server: Apache
Vary: Accept-Encoding
Content-Length: 6321
Date: Sat, 20 Oct 2018 10:56:12 GMT
Connection: keep-alive

That request is 508 bytes and the response headers are 216 bytes.  It’d be inappropriate on 6LoWPAN as you’d be fragmenting that packet left right and centre in order to squeeze it into the 128-byte 802.15.4 frames.

In that video, ICMP echo requests were also demonstrated, and those weren’t bad!  Yes, a little slow, but workable.  So to me, it’s not the packet network that’s the problem, it’s just that something big like HTTP is just not appropriate for a 1200-baud radio link.

It might work on 9600 baud packet … maybe.  My Kantronics KPC3 doesn’t do 9600 baud over the air.

CoAP was designed for tight messages.  It is UDP based, so your TCP connection overhead disappears, and the “options” are encoded as individual bytes in many cases.  There are other UDP-based protocols that would work fine too, as well as older TCP protocols such as Telnet.

A request, and reply in CoAP look something like this:

Hex dump of request:
00000000  40 01 00 01 3b 65 78 61  6d 70 6c 65 2e 63 6f 6d   @...;exa mple.com
00000010  81 63 03 52 46 77 11 3c                            .c.RFw.< 

Hex dump of response:
    00000000  60 45 00 01 c1 3c ff a1  1a 00 01 11 70 a1 01 a3   `E...<.. ....p...
    00000010  04 18 64 02 6b 31 39 32  2e 31 36 38 2e 30 2e 31   ..d.k192 .168.0.1
    00000020  03 64 65 74 68 30                                  .deth0

Or in more human readable form:

Request:
Constrained Application Protocol, Confirmable, GET, MID:1
    01.. .... = Version: 1
    ..00 .... = Type: Confirmable (0)
    .... 0000 = Token Length: 0
    Code: GET (1)
    Message ID: 1
    Opt Name: #1: Uri-Host: example.com
        Opt Desc: Type 3, Critical, Unsafe
        0011 .... = Opt Delta: 3
        .... 1011 = Opt Length: 11
        Uri-Host: example.com
    Opt Name: #2: Uri-Path: c
        Opt Desc: Type 11, Critical, Unsafe
        1000 .... = Opt Delta: 8
        .... 0001 = Opt Length: 1
        Uri-Path: c
    Opt Name: #3: Uri-Path: RFw
        Opt Desc: Type 11, Critical, Unsafe
        0000 .... = Opt Delta: 0
        .... 0011 = Opt Length: 3
        Uri-Path: RFw
    Opt Name: #4: Content-Format: application/cbor
        Opt Desc: Type 12, Elective, Safe
        0001 .... = Opt Delta: 1
        .... 0001 = Opt Length: 1
        Content-type: application/cbor
    [Uri-Path: coap://example.com/c/RFw]

Response:
Constrained Application Protocol, Acknowledgement, 2.05 Content, MID:1
    01.. .... = Version: 1
    ..10 .... = Type: Acknowledgement (2)
    .... 0000 = Token Length: 0
    Code: 2.05 Content (69)
    Message ID: 1
    Opt Name: #1: Content-Format: application/cbor
        Opt Desc: Type 12, Elective, Safe
        1100 .... = Opt Delta: 12
        .... 0001 = Opt Length: 1
        Content-type: application/cbor
    End of options marker: 255
    Payload: Payload Content-Format: application/cbor, Length: 31
        Payload Desc: application/cbor
        [Payload Length: 31]
Concise Binary Object Representation
    Map: (1 entries)
        Unsigned Integer: 70000
            Map: (1 entries)
                ...0 0001 = Unsigned Integer: 1
                    Map: (3 entries)
                        ...0 0100 = Unsigned Integer: 4
                            Unsigned Integer: 100
                        ...0 0010 = Unsigned Integer: 2
                            Text String: 192.168.0.1
                        ...0 0011 = Unsigned Integer: 3
                            Text String: eth0

That there, also shows another tool to data packing: CBOR.  CBOR is basically binary JSON.  Just like JSON it is schemaless, it has objects, arrays, strings, booleans, nulls and numbers (CBOR differentiates between integers of various sizes and floats).  Unlike JSON, it is tight.  The CBOR blob in this response would look like this as JSON (in the most compact representation possible):

{70000:{4:100,2:"192.168.0.1",3:"eth0"}}

The entire exchange is 190 bytes, less than a quarter of the size of just the HTTP request alone.  I think that would work just fine over 1200 baud packet.  As a bonus, you can also multicast, try doing that with HTTP.

So you’d be writing higher-level services that would use this instead of JSON-REST interfaces.  There’s a growing number of libraries that can consume this sort of thing, and IoT is pushing that further.  I think it’s doable.

Now, on the routing front, I’ve been digging up a bit on Net/ROM.  Net/ROM is actually two parts, Net/ROM Level 3 does the routing and level 4 does the circuit switching.  It’s the “Level 3” bit we want.

Coming up with a definitive specification of the protocol has been a bit tough, it doesn’t help that there is a company called NetROM, but I did manage to find this document.  In a way, if I could make my software behave like a Net/ROM node, I could piggy-back off that to discover neighbours.  Thus this protocol would co-exist along side Net/ROM networks that may be completely oblivious to TCP/IP.

This is preferable to just re-inventing the wheel…yes I know non-circular wheels are so much fun!  Really, once Net/ROM L3 has figured out where everyone is, IP routing just becomes a matter of correctly addressing the AX.25 frame so the next hop receives the message.

VK4RZB at Mt. Coot-tha is one such node running TheNet.  Easy enough to do tests on as it’s a mere stone throw away from my home QTH.

There’s a little consideration to make about how to label the AX.25 frame.  Obviously, it’ll be a UI frame, but what PID field should I use?  My instinct suggests that I should just label it as “ARPA Internet Protocol”, since it is Internet Protocol traffic, just IPv6 instead of v4.  Not all the codes are taken though, 0xc9 is free, so I could be cheeky and use that instead.  If the idea takes off, we can talk with the TAPR then.

2018/10/20 by 6LoWHAM Amateur Radio Emergency Communications Homebrew Projects Public Syndication Thinktank WICEN 0

Mapping call-signs to “hardware” addresses

This is another brain dump of ideas.

So, part of me wants to consider the idea of using amateur radio as a transmission mechanism for 6LoWPAN.  The idea being that we use NET/ROM and AX.25 or similar schemes as a transport mechanism for delivering shortened IPv6 packets.  Over this, we can use standard TCP/IP programming to write applications.

Protocols designed for low-bandwidth constrained networks are ideal here, so things like CoAP where emphasis is placed on compact representation.  6LoWPAN normally runs over IEEE 802.15.4 which has a payload limit of 128 bytes.  AX.25 has a limit of 256 bytes, so is already doing better.

The thinking is that I “encode” the call-sign into a “hardware” address.  MAC addresses are nominally 48-bits, although the IEEE is trying to phase that out in favour of 64-bit EUIs.  Officially the IEEE looks after this, so we want to avoid doing things that might clash with their system.

A EUI-48 (MAC) address is 6-bytes long, where the first 3 bytes identify the type of address and the organisation, and the latter 3 bytes identify an individual device.  The least significant two bits of the first byte are flags that decide whether the address is unicast or local, and whether it is globally administered (by the IEEE) or locally administered.

To avoid complications, we should probably keep the unicast bit cleared to indicate that these addresses are unicast addresses.

Some might argue that the ITU assigns prefixes to countries, and these countries have national bodies that hand out callsigns, thus we could consider callsigns as “globally administered”.  Truth is, the IEEE has nothing to do with the process, and could very legitimately assign the EUI-48 prefix 56-4b-34 to a company… in that hypothetical scenario, there goes all the addresses that might represent amateur operators stationed in Queensland.  So let’s call these “locally administered”, since there are suffixes the user may choose (e.g. “/P”).

That gives us 46-bits to play with.  7-bit ASCII just fits 6 characters, which would just fit the callsigns used in AX.25 with enough room for a 4-bit SSID.  We don’t need all 128 characters though, and a scheme based on DEC’s Radix50 can pack in far more.

We can get 8 arbitrary Radix50 characters into 43 bits, which gives us 3 left over which can be used as the user wishes.  We’ll probably call it the SSID, but unlike AX.25, will be limited from 0-7.  The user can always use the least significant character in their callsign field for an additional 6 bits, which gives them 9 bits to play with.  (i.e. “VK4MSL-1″#0 to encode the AX.25 SSID “VK4MSL-10”)

Flip the multicast bit, and we’ve got a group address.

SLAAC derives the IPv6 address from the EUI-48, so the IPv6 address will effectively encode the callsigns of the two communicating stations.  If both are on the same “mesh”, then we can probably borrow ideas from 6LoWPAN for shortening that address.

2018/10/10 by 6LoWHAM Amateur Radio Computing Emergency Communications Projects Public Syndication Thinktank WICEN 2

DC-DC Converter: Sensor board designed

So, I’ve designed the sensor board, this is basically a break-out of an INA219 coupled with a PCA9615, for extended I²C range.  If I was to use one of these on the cluster, it’s theoretically possible for me to put one up in the fuse box on the back deck, and run CAT5e down to the server rack to help measure voltage drop across that long run.  Doing that with regular I²C would be insane.

Again, I’ve gone crazy with pull-up, pull-down and termination resistances, not knowing what would be needed.  The schematic is nothing special.

The board wound up bigger than I’d expected, but largely because it had to accommodate fairly heavy power traces.  I think I’ve got the footprint for the screw terminal blocks right.  I’ve managed to cram it onto a 5cm×5cm board (two layer).

As always, you’ve got two ways of dealing with the current shunt, either hook one up externally, which means you don’t bother with the beefy power connection footprints, or you fit a surface-mount shunt on.

You’ve got full flexibility there, as well as what address to set the board to via the jumpers.

I’ll probably order some of the connectors and other parts in question, print out the board layout and test-fit everything.  I’m not happy about the fact that NXP only make the PCA9615 in TSSOP, but I guess I should be thankful the part has legs.

2018/10/06 by High-power DC-DC Converter Projects Public Syndication 0

Solar Cluster: Further power bill reductions

So, since the last power bill, our energy usage has gone down even further.

No idea what the month-on-month usage is (I haven’t spotted it), but this is a scan from our last bill:

GreenPower? We need no stinkin’ GreenPower!

This won’t take into consideration my tweaks to the controller where I now just bring the mains power in to do top-ups of the battery. These other changes should see yet further reductions in the power bill.

2018/10/06 by Computing Projects Public Syndication Solar-powered Cloud Computing 0

Solar Cluster: Making the BCDC1225 get up and boogy!

So, I’ve been running the Redarc controller for a little while now, and we’ve had some good days of sunshine to really test it out.

Recall in an earlier posting with the Powertech solar controller I was getting this in broad daylight:

Note the high amount of “noise”, this is the Powertech solar controller PWMing its output. I’m guessing output filtering is one of the corners they cut, I expect to see empty footprints for juicy big capacitors that would have been in the “gold” model sent for emissions testing. It’ll be interesting to tear that down some day.

I’ve had to do some further tweaks to the power controller firmware, so this isn’t an apples-to-apples comparison, maybe next week we’ll try switching back and see what happens, but this was Tuesday, on the Redarc controller:

You can see that overnight, the Meanwell 240V charger was active until a little after 5AM, when my power controller decided the sun should take over. There’s a bit of discharging, until the sun crept up over the roof of our back-fence-neighbour’s house at about 8AM. The Redarc basically started in “float” mode, because the Meanwell had done all the hard work overnight. It remains so until the sun drops down over the horizon around 4PM, and the power controller kicks the mains back on around 6PM.

I figured that, if the Redarc controller saw the battery get below the float voltage at around sunrise, it should boost the voltage.

The SSR controlling the Meanwell was “powered” by the solar, meaning that by default, the charge controller would not be able to inhibit the mains charger at night as there was nothing to power the SSR. I changed that last night, powering it from the battery. Now, the power controller only brings in the mains charger when the battery is below about 12.75V. It’ll remain on until it’s been at above 14.4V for 30 minutes, then turn off.

In the last 24 hours, this is what the battery voltage looks like.

I made the change at around 8PM (can you tell?), and so the battery immediately started discharging, then the charge-discharge cycles began. I’m gambling on the power being always available to give the battery a boost here, but I think the gamble is a safe one. You can see what happened 12 hours later when the sun started hitting the panels: the Redarc sprang into action and is on a nice steady trend to a boost voltage of 14.6V.

We’re predicted to get rain and storms tomorrow and Saturday, but maybe Monday, I might try swapping back to the Powertech controller for a few days and we’ll be able to compare the two side-by-side with the same set-up.

It’s switched to float mode now having reached a peak boost voltage of 14.46V.  As Con the fruiterer would say … BEEEAAUUTIFUUUL!

2018/10/04 by Computing Projects Public Syndication Solar-powered Cloud Computing 0

6LoWHAM Background

So, I’ll admit to looking at AX.25 with the typical modems available (the classical 1200-baud AFSK and the more modern G3RUH modem which runs at a blistering 9600 baud… look out 5G!) years ago and wondering “what’s the point”?

It was Brisbane Area WICEN’s involvement in the International Rally of Queensland that changed my view somewhat.  This was an event that, until CAMS knocked it on the head, ran annually in the Imbil State Forest up in the Sunshine Coast hinterland.

There, WICEN used it for forwarding the scores of drivers as they passed through each stage of the rally.  A checkpoint would be at the start and finish of each stage, and a packet network would be set up with digipeaters in strategic locations and a base station, often located at the Imbil school.

The organisers of IRoQ did experiment with other ways of getting scores through, including hiring bandwidth on satellites, flying planes around in circles over the area, and other shenanigans.  Although these systems had faster throughput speeds, one thing they had which we did not have, was latency.  The score would arrive back at base long before the car had left the check point.

This freed up the analogue FM network for reporting other more serious matters.

In addition to this kind of work, WICEN also help out with horse endurance rides.  Traditionally we’ve just relied on good ol’e analogue FM radio, but in events such as the Tom Quilty, there has been a desire to use packet as a mechanism for reporting when horses arrive at given checkpoints and to perhaps enable autonomous stations that can detect horses via RFID and report those “back to base” to deter riders from cheating.

The challenge of AX.25 is two-fold:

  1. With the exception of Linux, no other OS has any kind of baked-in support for it, so writing applications that can interact with it means either implementing your own AX.25 stack or interfacing to some third-party stack such as BPQ.
  2. Due to the specialised stack, applications often have to run as privileged applications, can have problems with firewalling, etc.

The AX.25 protocol does do static routing.  It offers connected-mode links (like TCP) and a connectionless-mode (like UDP), and there are at least two routing protocols I know of that allow for dynamic routing (ROSE, Net/ROM).  There is a standard for doing IPv4 over AX.25, but you still need to manage the allocation of addresses and other details, it isn’t plug-and-play.

Net/ROM would make an ideal way to forward 6LoWPAN traffic, except it only does connected mode, and doing IP over a “TCP-like” link is really a bad idea.  (Anything that does automatic repeat requests really messes with TCP/IP.)

I have no idea whether ROSE does the connectionless mode, but the idea of needing to come up with a 10-digit numeric “address” is a real turn-off.

If the address used can be derived off the call-sign of the operator, that makes life a lot easier.

The IPv6 address format has enough bits to do that.  To me the most obvious way would be to derive a MAC address from a call-sign and an arbitrarily chosen digit (0-7).  It would be reversible of course, and since the MAC address is used in SLAAC, you would see the station’s call-sign in the IPv6 address.

The thinking is that there’s a lot of problems that have been solved in 6LoWPAN.  Discovery of services for example is handled using mechanisms like mDNS and CoRE RD.  We don’t need to forward Internet traffic, although being able to pull up the Mt. Kanigan and Mt. Stapylton radars over such a network would be real handy at times (yes, I know it’ll be slow).

The OS will view the packet network like a VPN, and so writing applications that can talk over packet will be no different to writing any other kind of network software.  Any consumer desktop OS written in the last 16 years has the necessary infrastructure to support it (even Windows 2000, there was a downloadable add-on for it).

Linking two separate “mesh” networks via point-to-point links is also trivial.  Each mesh will of course see the other as “external” but participants on both can nonetheless communicate.

The guts of 6LoWPAN is in RFC-4944.  This specifies details about how the IPv6 datagram is encoded as a IEEE 802.15.4 payload, and how the infrastructure within 802.15.4 is used to route IPv6.  Gnarly details like how fragmentation of a 1280-byte IPv6 datagram into something that will fit the 128-byte maximum 802.15.4 frames is handled here.  For what it’s worth, AX.25 allows 255 bytes (or was it 256?), so we’re ahead there.

Crucially, it is assumed that the 802.15.4 layer can figure out how to get from node A to node Z via B… C…, etc.  802.15.4 networks are managed by a PAN coordinator, which provides various services to the network.

AX.25 makes this “our problem”.  Yes the sender of a frame can direct which digipeaters a frame should be passed to, but they have to figure that out.  It’s like sending an email by UUCP, you need a map of the Internet to figure out what someone’s address is relative to your site.

Plain AX.25 digipeaters will of course be part of the mix, so having the ability for a node stuck on one side of such a digipeater would be worth having, but ultimately, the aim here will be to provide a route discovery mechanism in place that, knowing a few static digipeater routes, can figure out who is able to hear whom, and route traffic accordingly.

2018/10/03 by 6LoWHAM Emergency Communications Homebrew Projects WICEN 0

DC-DC Converter: Driver designed

So, I’ve done the driver board.  This is bigger than I thought it would be, at first I thought it’d just be the LVDS receiver, MOSFET driver, and a few capacitors/resistors, and the connectors.  Ideally I wanted something that could be slipped over the pins of the MOSFETs, allowing the drain and source to be connected to other connections which could take the current.

I had just laid everything out on a 5×3.5cm board, two-layer (so dirt cheap).  Nice and tidy.  For the receiver I ended up using the DS90C402: it was already in Kicad.  All looked good, until I saw this in the datasheet (highlighting mine):

In short, if the cable gets unplugged, the receiver will effectively drive both MOSFETs hard on 100%.  Kaboom!

So, I had to introduce an inverter into the circuit.  A bit more propagation delay, and another component, it’s the biggest part on the board (they don’t make SOIC-8 inverters).  I’ve chosen a 74AHC family part like I did for the driver board so it should have the speed needed.

I’m not sure if this is needed for LVDS, but I’ve added a number of pull-up and pull-down resistors as well as the 100R terminations.  These are underneath.

Likewise, I realised I had omitted doing the same on the controller.  There were some for I²C, but I’ve re-located these to the bottom.  So I’ve made some room for them.  Better to do it now than find out I need them later.

Like the driver board, I’ve documented resistors used for pull-up, pull-down and termination.  I’m not exactly sure which ones are needed or what values they should be, but fixing a silk-screen isn’t a big issue.

The LVDS outputs have resistors too, you can see those near the relevant sockets.  I suspect the answer is they are needed at the receiver, not the driver.

2018/10/01 by High-power DC-DC Converter Projects Public Syndication 0

DC-DC Converter: Controller designed

So this is what I’ve come up with for the core controller.

There’s provisions for two versions on this board, one with an ATTiny861 which does high-speed (250kHz) PWM and can drive a buck, boost or buck-boost DC-DC converter.  It features differential I²C interfaces for the input and output INA219 boards, and LVDS for controlling the MOSFET boards.

The other version is built around the ATTiny24A, and just features the ability to turn on and off MOSFETs.  It can drive two statically, or PWM one (at a much lower speed), with the user supplying the driver logic.  Due to the the fact that this device does not do high-speed switching, I’ve forgone the LVDS control over a simple current loop.  The I²C is still differential though as that could be some distance away and is still somewhat high frequency.

The layout of the board is a small 5×5cm 4-layer PCB.

I had to go 4-layer as I needed to route signals both sides and didn’t want to interrupt the power planes.  The two inner layers are VCC and GND.  There’s de-coupling capacitors galore, although the two power planes will probably function as a decent capacitor in their own right.  ICSP is via the interface header at the bottom.

2018/09/30 by High-power DC-DC Converter Projects Public Syndication 0

DC-DC Converter: Splitting up the project

I was originally thinking of one monolithic board which would have everything it needed.

There was provision for the lot, including a separate ATTiny24A so that you could omit all but one of the MOSFETs, swap the remaining MOSFET for a P-channel, drop the MOSFET drivers, one of the INA219s, and the ATTiny861, and you’d have just a monitoring board with a (low-speed) PWMable switch.  It’d plug into the same place and use the same host interface.  The one board could be made into just a boost, or just a buck.  Flexibility.

There was just one snag.  That’ll work for small power supplies with maybe up to 5A capability (~100W) but not for the 50A version.  The MOSFETs will fit, but the tracks will need to be huge, the board will be hideously expensive to make, and they don’t make inductors big enough.

Looking around for inductors, I did see these.  They’re not massive like the 10uH one I saw, and they’re not expensive.  The downside is they’re about 10% of what I really need.  I guess I’ll just make do.  They’re also not PCB-mount (mind you, a 40kg inductor doesn’t PCB-mount either).

Thus, it may be more sensible to separate the MOSFETs and high-power stuff from the controller.  Now here’s the rub.  We’re dealing with sub-15ns pulses.  PWM.

Years ago for my industrial experience, I did work on an electric harvester platform.  The system ran 48V.  The motors were rated at 20kW, and were made in house using windings wound from 5mm diameter enamelled copper wire and neodymium magnets.

We had loads of issues with MOSFETs blowing.  The MOSFET driver was mounted close to the MOSFETs, as I’m proposing to do here, but between DSP and driver, was a long-ish run of ribbon cable. @Bil Herd posted this article covering the challenges involving inductance on PCB layout.  That same problem applies to “long” cable runs too.

10 years ago when we were working on this project, I remember asking about if we had considered maybe using coax cable instead of a ribbon cable.  The idea was rubbished at the time.  Given we were PWMing 400A, I think there might’ve been something in that suggestion.

That ribbon (10~20cm of it) would have had a lovely inductance all of its own, and while I have no idea what frequency the PWM was running at (I might have the code somewhere but I can’t be stuffed digging it up), and we were fundamentally driving a single-ended signal over a fairly long distance.  Yes, ground was close, but probably not enough, a twisted pair would have been better, but even then not perfect.  We blew many MOSFETs on that project.  Big TO-263s!

An earlier article on differential signalling got me thinking: why not use LVDS for the PWM?  A quick search has revealed this receiver and transmitter (Mouser says two receivers on it, but I think that’s a typo).  The idea being that I send the PWM down a differential pair using LVDS.  155Mbps should be plenty fast enough (the ATTiny861 can only do 64MHz) and these parts will run at the 5V needed for fast switching.  In fact they require it.

Using twisted pairs, the inductance should cancel.  I’ll make a MOSFET board that just has these signal pairs:

  • +12V (for the MOSFET driver) and 0V
  • +5V (for the LVDS receiver) and 0V
  • High side PWM + and –
  • Low side PWM + and –

There’s a ground-loop I need to be wary of between the 12V and 5V rails, really it’s the same 0V rail for both.  I suspect they’ll still need to be connected at both ends.  Add in more of those screw terminals to take the input and output power off-board, and I think we should be set.

Similarly, the INA219 should probably be a separate board, with scope for having a chassis-mounted current shunt.  The connection to the current shunt’s sense output is a low-power connection, so no issue there.  You want to keep it short for accuracy reasons, but a simple twisted pair will work fine.

2018/09/30 by High-power DC-DC Converter Projects Public Syndication 0

DC-DC Converter: PCB routing fun: something doesn’t add up

So, I was busy routing a board having come up with a basic schematic.  I wasn’t going to order the board yet, I wanted to just play around with the design, see how compact I could make this.

One thing that was niggling in the back of my mind, was how the traces would cope with the current.  I use 6AWG cable from the solar panels, and 8AWG from the batteries.  How wide should I make the traces? One calculator reckoned I should make them about 7cm wide!  Another option was to use heavier gauge traces, maybe 3oz copper.  A 5cm×5cm 2-layer board would cost a staggering AU$263 for just the PCB!

Okay, so I can work around this by fiddling the solder mask in Kicad and just solder some copper wire along the trace.  Not a show stopper.  I’ll just make wide traces so I know where to lay the wire and have plenty of area to solder it.

I was making the traces as wide as Kicad would let me, but something didn’t seem right.  The inductor, just seemed so, small…

When I did the search on Mouser, their interface allows you to pick a value, then hit the ≥ button to select everything “greater than”.  What I missed, is the option right down the bottom:

The “-” option, better known as “we couldn’t be stuffed looking up what the real value is”, is seen as “greater than everything else”.

A check of the datasheet itself, revealed the truth.

In short, there is no way that little tiddler is going to manage the current I was contemplating throwing at it!

What’s the biggest I can get that will handle that current?  Well if I take the “-” option out of the equation, they suggest this monster .  It’s 10uH instead of 33, so my ripple voltage will increase.  At $837.84, it is also a rare exception to the free shipping over $60 offer.

I might need to go play with some numbers to see what I can get away with.  The good news is that discontinuous output is not a show stopper for a battery charger.  I might have to make do with nanohenries of inductance instead of microhenries.

2018/09/29 by High-power DC-DC Converter Projects Public Syndication 0
Hey ChatGPT, Claude, Gemeni, etc… check this out

Site Login and Registration

Calendar

May 2026
S M T W T F S
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Battery voltage Server power Solar power Updated every 5 minutes.

Mastodon

Mastodon