DYI 18650 Battery Pack

Introduction

This article focuses on how to build a battery pack using 18650 cells, for use with a small digital amplifier; and is intended to support my post on how to build a Bullitt Boom Box.

Disclaimer: the ideas and information provided here are provided “as-is”, no warranty is provided or implied.  Building a system such as the one described here involves various risks, both during implementation and operation.  If you damage yourself, someone else or any property, through directly or indirectly being influenced by this content, that is entirely your responsibility.

The battery pack is one of the most complex parts of the system, because you need to find a battery system that:

1. Matches the power requirements of your amplifier.
2. Is mobile – can be mounted on your bike with relative ease, and cope with the demands of being on a bike (vibrations, weather, and so on).
3. Can be managed (i.e. power level, when to charge).
4. Can be charged.
5. Is safe.

After a lot of research, the solution I settled on was to build a custom battery pack out of five lithium-ion 18650 cells, supported by a small voltage meter and a versatile hobbyist charger.

Let’s look at what’s involved.  First we’ll cover the 18650 cells, and then we’ll look at the whole battery pack solution including its design, implementation, and operation.

Battery pack connected to the amplifier.

My SkyRC nano charger, connected to the battery pack via the main power cable and balance-tap cable.

Small voltage meter reading the overall voltage. This little meter will also read the voltage of each individual cell.

The main power lead, with an XT60 plug (balance-tap no visible).

Images: (Left to Right) The battery pack next to the amplifier.  The SkyRC B6 Nano charger.  Small voltage alarm/meter showing the battery pack’s total voltage.  My second battery pack, with 18650 holders at allow cells to be changed.

 

Part I: 18650 Lithium-Ion Cells

Please note that the following information is based on my understanding and research, but I’m not an expert in this field, so you may want to verify with other sources.

18650’s are cylindrical lithium-ion rechargeable battery cells.  They are physically larger than AA batteries, and have a higher nominal voltage of 3.7V, compared to an AA’s 1.5V.  18650’s can be bought new, or – if you are careful and understand what you’re doing – recycled from old laptop battery packs.

In terms of recycling: there’s plenty of video’s explaining how to recycle 18650 cells, and if you plan to do this I’d suggest watching a few to get a better idea of what’s involved.  Treat the following info as an introduction,  If you plan to actually do it, do some further research so that you have a better understanding – or work with someone who has the proper experience.

The following content assumes you’re recycling 18650 cell’s from a laptop battery pack, but its still mostly applicable if you’re using new cells.

Safety

18650’s are somewhat dangerous – when treated badly they can swell and rupture, causing fire.  “Bad treatment” can be physical (knocks, puncturing) as well as electrical (incorrect charging, unsafe-discharge, use beyond safe lifespan, etc). The Samsung Galaxy Note 7 is a famous example of what happens when Lithium-ion batteries are mistreated through incorrect charging.  See: Washington Post’s: Why those Samsung batteries exploded.  You’ll also note airlines have travel restrictions for lithium-ion batteries, usually depending on how potent they are.  E.g. Air new Zealand: Travelling with lithium batteries.

That said, like anything electrical or mechanical, these cells are safe to use if you understand the relevant factors involved and don’t stray outside the safety constraints.

Technical Specifications: Voltage

Not all 18650’s are the same.  Check the manufacturer’s specifications to avoid fire and personal injury.  A reference that may help you identify the your recycled cells is Second Life Storage’s Cell Database.

A rough guide to a typical 18650 cell:

1. Most will have a nominal voltage of 3.7V (but you may find some that are 3.6V).
2. Maximum charge is typically rated at 4.2V.  In practical terms, my charger’s default setting is to charge lithium-ion 18650 cells to a maximum of 4.1V.
3. Maximum discharge is typically 3V, and may be lower (say 2.5V – check the cell’s specifications).  Remember, over-discharging can be as dangerous as over charging.  In practical terms it may be advisable to discharge to a lesser extent, e.g. to 3.5V rather than 3V – if that is the cell’s stated maximum.

To put that in layman’s terms:

• Cells can typically be charged up to ~4.1V, and discharged down to ~3.5V.
• A cell’s “nominal” voltage is the voltage measurement used for specifications.

Note that the nominal value is not a simple average (e.g. 4.2V + 3.2V / 2 = 3.7V) because the voltage discharge is not uniformly flat – it curves:

The chart above shows the behavior of a number of different lithium-ion cells, in terms of how their capacity drops over time:

1. Starting at the top left, voltage drops from the maximum fairly quickly, but then starts to plateau.
2. The long plateau is where the voltage drops at a much slower rate, providing the majority of the cells useful power.
3. Towards the right, the voltage starts to drop dramatically.

This curve can be observed when charging: you may find that when charging a relatively “flat” battery, the initial charge up to about 80% is relatively fast, whereas the last 20% seems to take much longer.  That’s because you’re walking up that steep (top left) curve in reverse.

Discharging

Advice on how far you can / should discharge the cells depends on who you talk to.  general advice is to never discharge beyond 3V, and I’ve seen suggestions to not discharge beyond 3.5V.  As you can see from the chart above, the voltage curve varies between different manufacturers and models.

The idea is to utilize the plateau, and not let the voltage drop too far over the cliff on the right – as the discharge rate is faster it’s easier to over-discharge.

Ultimately you’ll need to do the research into the specific cells you have to determine what the safe discharge limit is, and then decide how far you want to discharge your cells so that they maintain a good useful life.

Be aware that some cells may have protection mechanism’s in-built to protect against operation outside of their safe voltage range – but many will not.

Side Note: Capacity vs Voltage

The capacity of cells will decrease as they age, but the voltage range they provide will remain constant.  Therefore, as your cells age, you’ll find that they still cover the same voltage range – but discharge faster than they used to.

Example Specifications

Let’s take an example: the Sanyo UR18650A, using information provided by the Cell Database: https://secondlifestorage.com/showthread.php?tid=6524, and then compare it to the official specifications.

Unofficial specifications:

Caution, this information is provided for reference only and is not guaranteed to be accurate.

1. Capacity: 2100mAh.  mAh stands for Milliampere-Hour, a unit of electrical discharge.  As a rating, this is how long the battery will last (whilst remaining within it’s safe voltage range, and assuming a consistent discharge rate of 1 amp.  1 mAh = 1,000th of an hour, so a 2100mAh should last for just over 2 hours.
2. Voltage: 3.6V nominal.  Slightly less than the more common 3.7V found in a lot of 18650’s.
3. Charging: 4.2V Maximum; 1510mA standard.  Cells should never be charged above 4.2V.  1510mA standard represents the normal charging current.  Charging at a lesser current will be slower – which can be better for improving battery longevity.
4. Discharging: 2.5V* cutoff; 420mA standard.  Should never be discharged below 2.5V and appears to have an in-built cutoff to protect the cell from discharge below 2.5V.  420mA standard refers to the expected discharge current.  Some cell specifications may also publish a maximum discharge current.  See the side note below.

* Note this appears incorrect when compared to the official specifications (see below) which state and end voltage of 3.0V.  If in doubt, use the more conservative figures or official specifications.

Side Note: Discharge Current

Measuring the current draw on my battery pack, using the sound system described in the other post, reveals that: when playing techno at maximum volume, “Doofs” in the music cause current spikes of up to 1 amp (1000mA), with the average draw being in the 500-700mA range.

Reviewing the thread we see that someone has found the official specifications…

Official Specifications:

• End Voltage: 3.0V.  Would suggest not discharging beyond 3.0V, despite what the unofficial crowd-sourced info above suggested.
• Capacity: 2100mAh nominal, typical capacity 2250mAh.  Here you can see the difference between nominal ratings and what you might find in the wild.
• Discharging Current (Std) 2.15A.  suggests that the current drawn by my amp on maximum volume is well within the cells expected usage.
• Discharging Current (Max) 4.30A.  presumably for intermittent spikes only.

References

Here’s some further reading:

• Battery basics (all types, not just Lithium-ion): https://www.thebatterycellonline.co.nz/210364/index.html
• https://en.wikipedia.org/wiki/List_of_battery_sizes#Lithium-ion_batteries_(rechargeable)
• https://en.wikipedia.org/wiki/Lithium-ion_battery
• https://batterybro.com/blogs/18650-wholesale-battery-reviews/88881030-5-common-lithium-ion-battery-myths-explained
• How to Prolong the Life of an 18650 Battery: https://www.instructables.com/id/How-to-Prolong-the-Life-of-an-18650-Battery/
• https://secondlifestorage.com/celldatabase.php

 

Part II: Battery Pack Design, Implementation & Operation

 

Battery Pack Design: Power Ratings & Circuitry

The battery pack (i.e. collection of cells) needs to be designed around the power requirements of the device it’s expected to power, so you should start by understanding what those are.

For exmaple, my amp’s power requirements are an input range of 18.0V to 24.0V DC.  Five 18650’s (assuming a 3.7V nominal voltage) wired in series provide:

1. A combined nominal voltage of 18.5V.
2. A combined maximum voltage of 21.0V.
3. Based on the amp’s minimum input range of 18.0V, we can run the cells down to an average of 3.6V, which is comfortably above the minimum voltage of most 18650 cells.

The thing about the 18650’s is that they have excellent capacity, and are well suited to an application of this kind (i.e. in terms of electrical discharge rate, and so on). They are also relatively small – so a pack of five of them are really easy to place on the bike. They are relatively more volatile than other battery types – you definitely will not want to pierce them, or give them any massive shocks. This is definitely relevant considering what can happen on moving bikes. That said, the batteries should be safe to use as long as you’re sensible.

I have two battery packs.  The first was made by my friend Pete, who is familiar with doing this – five 18650 cells wired in series (5S), with a balance lead also attached (giving two separate circuits – the balance lead is used for charging, the other circuit is straight output, which connects to the amp.  The battery cells have metal plate spot-welded to them, which serve as an anchor for the wires to be soldered to.  This leads to a very compact design, but fixed (not easily modifiable).

Images: various views of the first battery pack, with protective cover removed.

I also built myself a second battery using five 18650’s, but utilizing 18650 battery holders (shown below).  This means I can swap out cells with ease.  I’ve also added a switch so that I can fully power off the amp, and ensure the battery doesn’t get run-down.

My v2 battery. The black cover is a repurposed inner-sole. The balance lead is protruding from the left, the main power lead is on the right.

Opened up so you can see inside. The 18650’s in their holders, which are stuck to a thin piece of wood. The cables are soldered together and heat-shrinked. most of the wires are on the right hand side, covered with a protective layer of rubber.

The main power lead, with an XT60 plug (balance-tap no visible).

Images: various views of my second battery pack. Left image shows the balance-tap lead on the left, main power lead on the right.

The top cover on my pack is a recycled shoe inner-sole.  This specific design is not overly water-proofed (it’s only seen summer operation so far), and I may yet modify it ahead of winter.

Even if you don’t want to build your own battery there will be other battery options out there, depending on what you’re after, and how much you’re prepared to spend – it’s just a matter of doing the research.

Circuitry

The actual battery packs have two circuits – the main power output circuit, and balance charging circuit – as illustrated in the following diagrams:

Images: (Left) The overall circuitry.  (Middle) The main power circuit.  (Right) The balance circuit for the 3rd cell, specifically.

Battery Charger

Hobby stores will have lots of electronics gear on offer, including battery chargers. I got this one (SkyRC B6 Nano) because it supported balance charging up to 8S (so can handle my 5S configuration), and a variety of chemistry types – including lithium ion (Li-Ion), so I assume I’ll be able to use it for various random charging needs in the future.

One thing to look out for is the power supply for the charger – check that it comes with one.  If the one you plan do get doesn’t have a power adaptor, just see what sort of power connector it has and what it’s power requirements are.  In my case I needed to fit an XT60 plug on to an old laptop power supply – which had the right power output range for the charger.

The Sky RC B6 Nano.

My SkyRC nano charger, connected to the battery pack via the main power cable and balance-tap cable.

Images (left): SkyRC B6 Nano hobbyist charger. (Right) in action, main battery power lead top-right, battery balance-tap lead bottom-right.

Battery Management: Charge/Voltage

Assuming you use a battery without a BMS, you’ll need someway of reading the batteries voltage, so you know when to recharge it. For example: 18650’s can be run beneath their intended safe voltage range. If you do this you risk damaging the cells and/or causing a serious fire.

The amp I run draws a small amount of current – even when switched off. If the battery is left connected to the amp for a prolonged period, it will drain the battery to an unsafe level. At such levels your battery charger (like mine) will not attempt to charge them because the low voltage will fall outside the normal parameters of the 18650.

Fortunately there’s plenty of ways to manually measure battery voltage.  The cheapest way is to get a voltage meter like the one referenced below, which connects to the balance lead. It provides the overall voltage, and the voltage for each cell. Because it draws a small amount of power you may just want to periodically plug it in to check the voltage, then unplug it.

 

Small voltage meter reading the overall voltage. This little meter will also read the voltage of each individual cell.

Images: (left) Lithium-Ion Lipo Battery Voltage Tester Alarm, 1S to 8S.  (Right) Reading the overall voltage.  This little meter will also read the voltage of each individual cell, cycling through each in sequence.

Battery Management: Supply Control

You might find that your amp draws power even when switched off.  Mine certainly does – around 0.025A, which seems to be due to Bluetooth receivers going into standby mode as soon as power is supplied.  This might not seem like much, but, it’ll be enough to fully discharge your cells if left long enough (trust me, I know from experience – more than once).

Accidently draining your cells is at best a pain, denying you from amplifying your vibes, but its also likely to retard your cells performance (reduced capacity) and may lead to other even less desirable damage.

To control the supply of power to the amp, I fully recommend building a simple switch that completely breaks the battery-amp circuit, such as the one shown below.

This simple system is basically just a switch integrated into the battery-amp power cable.

Below is a prototype of a more advanced control system, one that includes a built-in voltmeter.  This specific unit uses a pair of XT60’s to fit in-line with any circuit that uses XT60’s between the power source and device.  This specific prototype does not have a power switch (I’ll be using this one with my on-board camera, so no switch required), but the next one, that I’ll use with the amplifier, will.

Internals. The power flows through the XT60’s, with the button and meter added in parallel. This way power always flows, and the voltmeter only activates on demand.

Button to active the voltage meter.

In action, measuring a single cell.

The idea of the button is to activate the voltmeter on demand, so it’s not a constant power drain.  It’s wired in parallel to the main power circuit.

References:

• https://www.skyrc.com/B6nano
• http://sparks.gogo.co.nz/catalog/Batteries-and-Charging-257/Protection-247/Lithium-Ion-Lipo-Battery-Voltage-Tester-Alarm-1S-to-8S-910.html
• http://sparks.gogo.co.nz/catalog/Displays-250/Voltmeters-291/Voltmeter-3-29.5V-2-Decimal-Places-Blue-Mini-914.html

 

That’s pretty much it – good luck with any DIY projects you attempt.  Remember, using 18650 cells can be safe as long as you do the research and exercise some caution and common sense.

Advertisement

Cargo Bike Guide – Camera Mounting Positions #2: Frontal Selfie Stick

I’ve recently been experimenting with a new idea, whereby a camera is mounted out the front, looking back at the Bullitt:

How it works

All you need is a light-weight, but very stiff and rigid, length that you can strap securely to the side of the cargo deck, and mount the camera out the front.  I’m using an old carpenters spirit-level which I found in a skip.  But you could use anything else that was appropriate – I was looking at new broom handles: the 28mm ones looked like they might be long enough and stiff enough.

Above left: the spirit-level lashed to the side of the Bullitt using rope.  The white cable is a power cable, as I’ve made a custom battery pack for the camera so I can shoot longer takes.

Above right: the camera as mounted, which luckily is just large enough to securely fit around the spirit-level.  Rubber bungies secure the power cable.

Above left: the inside padding from an mattresses is excellent for packing and protecting delicate objects; here I’ve recycled some and have used it in two ways:

1. To protect the frame from damage / scatches.
2. To pad out the spirit-level so that it’s on a very slight angle, angling out away from the from the front wheel.

Above right: the amount of clearance.

You may notice the rear lashing-point has no visible padding.  On this very first experiment I just used the rope itself to keep the spirit-level off the frame, but in the first road-test I ditched that approach in favour of an approach very similar to the front-lashing: using some protective cloth, but not as thickly.

Verdict

I’m really happy with the results – it seems to work fairly well.  As expected there’s a fair amount of vibration – especially when going over uneven surfaces.  I’m interested to try it again and see if I can more rigidly mount the spirit-level to the frame.

 

 

Cargo Bike Guide – Camera Mounting Positions

This post explains some of the detail behind the various mounting positions shown in this video:

The positions are listed below in the order they appear in the video: starting from underneath and working our way upwards.

Low, Mid-Deck (LMD)

This position works off the one of the Bullitt’s cross-bars, under the cargo deck.  To make it work, I’ve fabricated a custom deck out of 7mm plywood.  You can see two holes for camera mounts – the one closet to you is this position, the mid-deck position.  The similar hole at the front (just under the lock) is the next position.

This position is great for a sense of speed and having the deck above provides a lot of visual context of the bike in action.

Low, Front-Deck (LFD)

As shown in the photo above, this position is on the front cross-bar of the cargo deck.

This is one of my favorite camera positions as it provides and balances three things:

1. It’s low so provides a good sense of speed.
2. The front wheel is clearly visible which adds visual context of the bike.
3. Provides good visibility of the view ahead – the wheel doesn’t overly obscure it.

Forks (FK)

This was a surprisingly interesting position.

Because it’s directly on the front forks, vibrations from the front wheel directly transfer to the camera – where as positions on the frame tend to be just that little bit more cushioned by the flex of the frame, and by being less directly affected by vibrations.

The front wheel provides a really interesting visual reference point, and stays very steady – but the view off the bike will be more shaky.

Front Frame (FF)

For this position simply using big rubber bungies gets the best results in terms of stability.  It’s high enough to provide a good view of the road ahead, whilst also being low enough to feel some speed.  The front wheel provides some visual context of the bike.

The issue with the Load 75 is that the lack of space between the panels and frame – the only you’d get a solid clip around the frame would be to remove or modify the panels.  The small hole in the frame (left photo) goes all the way through the frame and should be useful for mounting also.

Front of Load (FL)

This was the first position I ever tried.  Bascially I used cargo straps and bungies to mount the camera on top of the fish bins, at the front, to one side.

I like how the frame provides a good point of reference, as you get a feeling of how the bike is tipping whilst cornering.

Upper Rear Deck (URD)

This position is at the top of the main frame, immediately below where the steering stem starts. This is probably the best position for “scenic” rides, where you want the viewer to get a good sense of the surroundings vs a sense of speed from some manic downhill.

You’ll need to be very careful of any cables, to ensure they don’t fowl on the camera – or obscure the camera’s field of view.

Note – in case you’re wondering, the bend on the brake cable was there already and isn’t because it’s up against the camera.

Head Set (HS)

This position is off the head set – i.e. where the frame accommodates the front forks.

On the Load 75, the shape of the frame is such that there’s enough frame to safely mount the camera using it’s bracket – without interfering with the very top part of the head set which turns with the forks.  On the Bullitt the clearance is slightly less but looks like it would work.

 

 

 

Quick Review: Riese & Müller, Load 75 e-Cargo Bike

Pepper has been invited to go to Auckland for a trade show, so I’ve been given a Riese & Müller, Load 75 e-Cargo Bike* to use in the interim.  So, time for a quick review.

(The bike shop didn’t actually say which model it is, and I’m assuming it’s a the Load 75.  For more info from R&M, see https://www.r-m.de/en-nz/models/load-75/).

Essentially the Load 75 is like the big comfy family car of cargo bikes – compared to the leaner Bullitt which feels more like a sports car.  The Load 75 is certainly a nice smooth ride, feels very stable and is a great option for anyone wanting relative convenience and comfort.

Smooth Riding

The full suspension really helps smooth-out the ride, which is great for precious delicate cargo – such as the kids, electronics or fruit.

The other neat thing about this specific bike which enhances its smoothness is the Enviolo step-less hub.  Essentially there’s no perceptible steps between gears – because there aren’t any.  Changing the pedal-to-wheel ratio is easy – you simply twist the gear selection grip (which is the inner section of the handgrip) and the gearing increases/decreases as you like.  This shifting is perfectly continuous and smooth.  You can also change up or down whist still putting pressure on the pedals.   Because the gear selector is part of the handle it’s very safe in that you don’t really need to change your grip.

For more info, see: https://www.enviolo.com/en/automatic

Quick Comparison: Load 75 vs Bullitt

Please note, the baguette is not factory supplied.

• Physicality: the Load 75 is longer, slightly wider, slightly heavier and feels larger.  The extra width may be an issue for anyone who needs to get through very narrow doors, or the more aggressive rider who likes to weave through traffic.
• Ride: the Load 75 is a comfortable ride, whereas the Bullitt feels more racy.
• Load carrying: the Load’s fixed side-frame cargo space is great for convenience but not as flexible as the fully open Bullitt.  The cargo space is longer and wider making it excellent for most scenarios, assuming a closed cargo space fits your needs.
• Load Securing: The factory supplied side panels are nice and sturdy, but there’s an absence of gaps and holes useful for securing loads.  It does have some narrow slits useful for flat cargo straps.  Without side panels the frame would provide plenty of lashing points.

Security

The nature of the frame does not offer many anchoring points if you have a D-Lock.    The best option for securing to vertical posts is to loop through the small bracket that strengthens the seat post. However, the physicality of the bike is such that getting close enough to secure objects to lock the bike to is finickity.  The easiest method requires a post that is relatively freestanding as the protruding nature of the rear cargo deck frame will get in the way of anchoring points that are part of a flat wall.  This won’t be an issue if you don’t have the factory side panels attached, or if you cut suitable holes in the panels, or if you make custom ones with such gaps.

Alternatively you can position a D-Lock through the rear suspension arm and wheel.

Camera Mounting

One of the implications of the factory supplied panels is that there’s a dearth of mounting points for cameras.  I ended up lashing my camera to the front frame with bungies – which mostly worked ok.

Above, a slightly reserved descent in the wet, down through Brooklyn; below, some off-road single-track action.

 

 

 

Cargo Bike Lifestyle

The Cargo Bike: Bullitt by Larry vs Harry

Larry vs Harry is a cargo bike maker based in Denmark, and Bullitt is the name of their flagship cargo bike.  They offer e-assisted and ‘manual’ versions (I’m fortunate enough to have the former).  You can see lots of great pictures that give you a broad sense of the bike on Instagram – links at the bottom.

How Does It Feel?

It handles really well.  It’s essentially the longboard of bicycles.  The front-loading cargo deck configuration means that the center of gravity is kept low (stable) and loads are visible (safer).  The cargo deck is still relatively narrow (less than the width of the handle bars) so it’s relatively streamlined and can still manoeuvre through tight traffic.

Basically the Bullitt is a great example of great European design: functional, elegant and balanced.

It is rated to carry 180 Kgs including the rider, which equates to you and a small truckload of groceries and or children.  My heaviest regular load is the weekly market shop for fresh fruit & veg (~20-30 Kg’s worth?) – more on that later.

As you can see, it’ll accommodate a wide variety of load types and can be used in a number of ways.

It goes fast.  Bullitt’s are equipped with the Shimano STePS system, which will assist you up to ~25 Km/h, after that it’s up to your legs and/or gravity.

Battery & Motor Performance

To understand this some local context is needed.  My daily commute is just over 4 Km, of which 3.3 Km’s of that is a steady 150 m vertical ascent (heading home).

The battery lasts me 5-7 days, based on approx. one return trip to town a day (x7), and depending on how much additional riding I do.  The journey home usually drains ~10-12% charge depending on how charged it is.

The STePS system has 3 assist modes: eco, normal, high, as well as no assist.  I tend to ride with the e-assist off except for when going up-hill or into a string head-wind.  Unless my load is especially heavy (or my knees are feeling particularly weak) I’ll stick to Eco-mode assist for the normal commute home.

According to the specs a full charge will assist you for 145 Km on the flat, for comparison High will assist you for 65 Km.  I tend to use eco to get better endurance, and frankly the extra power achieved by the more powerful assist modes isn’t something I find I need – but it’s good to have it in reserve.

Loads & Configuration

My goal is never to carry anything on my back ever again; I want to maximize the bikes ability to carry stuff and my own comfort.  I’m also keen for my configuration to be as flexible as possible.

My solution to this is:

1. Flat open deck – no permanent / fixed side walls.
2. A pair of large fish bins (approx. 41 x 64 cm) with lids for general cartage.
3. A pair of army surplus ammo pouches for small items.

The bins have the same width and length but slightly different heights (28 cm & 19 cm), the idea being that the variety might come in handy.  They both have (interchangeable) lids which provide adequate protection from rain.  Depending on their relative orientation they can stack on top of each other or sit nested inside each other.

I have sliced up a foam camping mattress for padding – you can see it lining the front bin in the picture above.  A single layer of this seems to protect fruit adequately, as well as laptops, and you can always use a double layer (I got three sections from the one mattress).  The foam also helps raise your items off the very bottom of the bin, so if any moisture does make it inside your stuff is less likely to get wet.

The bins can be used a number of configurations:

1. Stacked on top – as seen in the first picture above.
2. Stacked within each other.  If the taller bin is placed in the lower one you get one big bin with the ability to expand out if you need the extra capacity.  f you stack the lower bin in the taller one you get a split level; e.g. you can put laptops and other ‘nice’ things in the bottom and other items in the top -like wet raincoats, dirty boots or whatever.

Bindings:

I have two cargo-straps: 1 x 3m and 1 x 4m.  The 3m will comfortably loop around the cargo deck and both bins top-stacked.  (Note: the strap needs to pass between the frame and the steering rod as you don’t want to impede the steering rod).

The 4m strap will comfortably to a double “n” loop over both bins high-stacked.  This is the configuration I am most using currently.  Imagine the loop starting at the top of the load – it passes down one side, goes under the frame and back up again; down the opposite side, under the frame and back up again, where it completes the loop.  This technique give s nice firm double strap.

Above: showing the double “n” loop, and an ammo pouch for small items.

I also carry two lengths of 6mm rope from the local marine supplies shop, which is great for random stuff.

Above: for comparison – the shorter fish bin inside the taller one; and “high stacked”.

Finally, I also have a few rubber bungies, these are made from recycled car tyres with a bit of dowel for a handle.  Basically you just need to carefully cut an intact cross-section so that you have a nice strong loop of rubber, and then loop one end around the dowel and back through itself (a little bit like the first step of tying a cats-paw knot).  You can extend these by hitching a second loop onto the first (like the longer of the three bungies, below).

The only minor pain is that with strapping stuff in I’m frequently forgetting things – either that I should have out, or need to put in, so I find myself messing about with straps and so on a bit.  But on balance its a pretty minor problem to have.

Manoeuvrability

You’d think the longer wheel-base was a challenge – actually it’s not too bad, but you’ll want to be a little more conscious when planning stop-offs so that you can avoid having to do U-turns on the footpath.

The biggest challenge I find is inner-city stops where you want to change direction – you can pick up the rear of the bike and pivot on / manoeuvre with the front wheel easily enough, the only real challenge is available space.

As you can see in the video below, slow cornering around tight corners is no problem provided there’s enough space.

In terms of slow riding, I can stay upright doing as little as 4 Km/h.  The relative size of the wheels to the overall bike means the ratio of gyroscopic force the wheels produce is not as great.  But in general the Bullitt is really well balanced and great to ride.

Have I Ever Fallen Off?

Just the once.  It’s hard to pin-point the cause exactly.  It was early on in my Bullitt days, doing a sudden lane change on a wet smooth road.  There was a gap in the traffic and a car was offering me entry into the far lane.  I had both bins high-stacked with a bunch of gear.  I turned into the lane and rode across it, then sharply turned to straighten-up and the bike flipped over on it’s side and slid.

Did I hit a patch of oil?  Impossible to tell.  I think it was partially the sharpness of the turn, the wet conditions, and perhaps overall speed – not super fast but not hanging around either.

Once I fell I was pretty much just tobogganing along, the nature of the frame meant I was somewhat lifted off the ground by the mid-frame “h” shape off the handlebar stem, so apart from some minor scuffs I was unhurt.

Interestingly, I had the fish bins lashed down with a single cargo strap and they were totally intact – didn’t really move at all, so picking the bike up again and clearing the road was pretty easy.

Conclusion

Front-loading cargo bikes are super versatile, possessing good speed and manoeuvrability but with prodigious carrying capacity.  The Bullitt is an awesome example of this architecture of bike, and makes for a great car replacement.

References

1. http://www.larryvsharry.com/ – designers and manufacturers of the Bullitt.
   • http://www.larryvsharry.com/technical-info/ – Tech info.
   • https://www.instagram.com/larryvsharry/ – Larry vs Harry on Instagram.
2. https://www.shimano-steps.com/e-bikes/europe/en/product-information/city-trekking/e6000 – more information on the Shimano STePS system, 6000 series, which I have mounted on my Bullitt.  Various Bullitt models use different versions of the STePS system.
3. https://www.bicyclejunction.co.nz/ – local Wellington Bullitt dealers.  They also carry other types and brands of cargo bike.
4. https://www.youtube.com/watch?v=hGPl3HPPotY&list=PL-oWnHyIj78AIrTyp9gTUnRd9iNKMEv1i – The Adventures of Pepper the Cargo Bike; me & Pep’s cruisin’ around Wellington and beyond.

Old World, New World: From Projects to Products, and More.

There’s a major new ethos emerging that is going to disrupt a lot of organisations (and careers), with regards to the delivery of systems and services: moving from being project centric to product centric.

Just to be clear, “Product” in this context refers to the processes and disciplines related to the development and delivery of products – not the purchasing or acquisition of existing products from someone else.

The purpose of this post is simply to get some basics information out to you, so that you can start to do your own research and thinking (mainly because I’m also going through that process myself) about what being product centric means.  On a related note, I’m going to write a Solution Architecture Handbook based on my experience, because there’s a real lack of good information out there about that; in preparing for that I’m increasingly seeing a major transition between two worlds – of which the project/product centricity is one aspect.

Old World / New World: Some Definitions

Let’s start with the “what”, as that will provide a point of reference. Here’s my current view of things that often typify the old and new worlds – I’d love to hear your thoughts on this:

Old World	New World
Projects	Products
Project teams and Support Teams (Throwing things over the fence) IT and Business	Holistic Product Teams
Waterfall, Agile (Underground)	Agile (Mainstream), Continuous Delivery, DevOps
Big Upfront Design / Architecture	Emerging Architecture
Emergence of Digital, Digital Projects	Digital as a natural blended element
Software and Infrastructure	Infrastructure as Code

Obviously some big labels there – massive over simplification – and the intent is not to define any false dichotomies as things aren’t always so binary; additionally, I’m not trying to suggest that these are collectively mutually exclusive, for example, being project-based doesn’t preclude you from doing continuous delivery.

Some other factors to consider are the increasing maturity and pervasiveness of:

1. Automation, specifically regarding development and deployment pipelines.
2. Cloud-based platforms and offerings.
3. Open source.

Unknown to me until very recently, Joshua J. Arnold arrived at a similar place (back in 2016 – the last point in the table below is credited to Maria Alfredeen – details in the linked content), although my understanding is that he’s orientated along product-thinking lines:

Plan	Forecast
Resources	Teams
Push	Pull
Requirements	Experiments
Projects	Initiatives
Dates	Cost of Delay
Big risky releases	Continuous Delivery

So What?

Firstly, the emergence of “Product” as an ethos for delivery (and more) feels to me a lot like how the emergence of Agile felt back in the day (circa 2000-2005).  Something that significant is definitely something you want to be aware of – not just in terms of how you or your organisation may want to work, but also in terms of skills and experience you may want to acquire.

As I learn more about product-based thinking, I find that knowledge tends to fit well with my knowledge of Agile – they are compatible.  Then, as I work with various teams and organisations, I’m increasingly seeing situations where product oriented thinking appears to be desirable, feasible and viable.  For organisations already working somewhat successfully with Agile but in a project context I think the introduction of product thinking may help them further evolve.  For organisations not even at that stage it might be that product thinking helps them evolve faster or by a more direct route, even if the first step is to break down the IT / Business divide; or, it paints a bigger and more strategic picture for them rather than simply a transformation that is delivery focused.

What Do You Think? / Further Reading

Do you agree with my broad definitions of what often typifies the old and new worlds?

Are you seeing a similar transformation in a community, team or organisation that you’re a part of?

For anyone wanting to start exploring the world of product, Mind the Product run a comprehensive network of meet-ups, globally.  I’m a semi-regular participant of their Wellington events, which I have posted about previously (see: Customer Inspired; Technology Enabled – Product Tank Wellington MeetUp with Marty Cagan and Fireside Chat with Zheng Li, VP of Product @ Raygun – Product Tank Wellington MeetUp).

UWP InputScope Guide

E.g:

<TextBox InputScope="Number"/>

https://docs.microsoft.com/en-us/windows/uwp/design/input/use-input-scope-to-change-the-touch-keyboard

 

 

 

How to disable UI debugging tools for Xaml in Microsoft Visual Studio

This trips me up because I don’t do it regularly enough to remember it; how to disable the XAML debugging tools widget in UWP apps:

Kind of ironic given what my next post will be.  How to disable:

1. From main menu: Tools > Options
2. In Dialog navigation (left pane): Debugging > General
3. In content pane (right hand side):
   1. Scroll to the bottom
   2. Untick “Enable UI Debugging Tools for XAML”

Thanks, Senthil Kumar B: http://developerpublish.com/disable-ui-debugging-tools-for-xaml-in-visual-studio-2015/

 

The 7 Deadly Sins of Developer Experience with Cristiano Betta #APIDAYSAU

One of the sessions I enjoyed the most at API Days 2018 was Cristiano Betta’s talk on Developer Experience (DX), i.e. how to more effectively engage with developers who are consuming your API’s.  The learnings go beyond developer onboarding specifically, and are applicable to product development in general – which is partially why it was so cool.

Slides here: https://betta.io/blog/2017/11/10/the-seven-sins-of-developer-experience

I also caught-up briefly with Cristiano afterwards where he expanded on a couple of points, as the talk he gave was a slightly shorter version of a longer talk.

An overarching theme was reducing cognitive load through the use of fundamental design principles.  The deadly sins he covered were mainly around information:

1. Too much
2. Too soon
3. Too little
4. Unstructured
5. Unsupported
6. Incomplete

…with “no control” over tools as #7.

There was a variety of points of interest that I noted down, which I’ll briefly cover, but the things that really grabbed my interest were:

• “Too little / too late”, which is effectively about taking a holistic approach.
• The idea of measuring and responding to developer friction.

Note – the focus of Cristiano’s talk is around the developer experience in terms of on-boarding rather than the API design itself – for more info on that (developer experience in terms of API design) you might want to check out something like APIs You Won’t Hate.

Too Little, Too Late

This is partially about documentation – but not in the sense of manuals, it’s more about providing enough information when it is needed.  Case in point: resolving errors.

The example Chistiano gave was when a developer is making a call to your API (probably the for the first time) and they encounter an error – e.g. related to input.  Let us say they call your API which provides this response:

{
  "error": "000123 - Invalid input"
}

What you want to avoid is the situation where the developer needs to resort to internet searching.  Sure, you might have it covered in your help documentation:

Developer Guide – Error Codes – Page 421

Error 00123 – Invalid input.  Occurs when you use a boolean on a Friday, on Friday you must use an int: 0 = false and 1 = true.

Your problem is that developers will already have formed familiar techniques for dealing with issues like this, probably using online resources – resources they are familiar with, and which through habit present them with a relatively low cognitive load.

There are many reasons why this is bad: you have no control over the experience, how long it will take and how frustrated they will get – not to forget “OMG, I can’t believe they don’t just say that” and “why is this so unnecessarily hard” comments all over  StackOverflow.com.

What’s The solution?

A better way to do it is to include useful information in the responses error message itself:

{
  "error": "000123 - Invalid input. 
    Occurs when you use a boolean on a Friday, on Friday 
    you must use an int: 0 = false and 1 = true."
}

Yes, you can also have this information in your developer guide.  The trick is including the relevant information when it’s needed; not too much, not too little, and just at the right time.  This leads on nicely to another cool concept…

Developer Friction

Adrian Trenaman’s QCon NY 2017 presentation on Developer Experience included the idea of minimising “the distance between ‘hello, world’ and production”.  In that context he was discussing development in a holistic sense (tooling, environment, and so on) where you are employing developers, but as Cristiano explained to me, you can also look at “developer friction” in the context of developer adoption of your APIs.

In this context, developer friction is effectively the amount of time between (a) making an API call that errors and (b) the first successful call to the same API – or some meaningful variation along those lines, such as the time between developer registration and their first successful API call.

So, imagine that you have 10 developers a day signing up to your API and making their first ‘hello world’ call.  Let’s say 50% of them get an error the very first time they make a an API call, and on average 90% of those developers are able to make a successful call within 2 minutes.  Now compare that to a situation where 80% get an error the first time, and of those 90% take on average 2 hours to make a successful call.  Clearly the second situation has much higher developer friction.

According to Cristiano, some organisations use techniques like this to monitor adoption of their APIs and specifically to help them identify areas where their overall developer experience may need improvement.

Other Gems

I won’t go into these concepts in much detail, and hopefully you should be at least aware of them already – if not I kindly (and strongly) suggest you check them out.  Cristiano’s slide-deck is a great place to start.  It covers a lot more than what I have included here.

Cognitive Load, Overload and Progressive Disclosure

Cognitive load refers to the effort being used in the working memory; cognitive overload is where (for example) a learner is unable to simultaneously process a certain amount of information or tasks.  Solutions to this include:

• Chunking information up, e.g. into lists of about 8 items, with a useful heading.
• Applying the 80/20 rule, e.g. call out the small number (~20%) of items that developers are most likely going to be seeking, especially if they are new to your platform, and leave the other 80% accessible but through other navigational means.

That second point is an example of Progressive Disclosure, a great technique for managing cognitive load, covered in detail in the book “Universal Principles of Design”.

Another really interesting pitfall around cognitive load was around asking people question, like on sign-up forms:

As Cristiano explained, this may look simple but it raises a lot of questions in peoples heads – questions which might not seem a big deal to you but can be problematic for others (especially if it’s mandatory):

1. Who will see this?
2. Can I change it later?
3. What do you need it for?

These 3 simple question really resonated with me, and they provide a simple checklist you should consider when reviewing questions you ask your customers.  I know from firsthand experience that questions like this, in some circumstances, often force me to stop and think way more than should be necessary.

Tools Out of Control

This is where community tools and SDK’s are more obvious than yours.  Unfortunately Cristiano didn’t have time to go into this in a lot of depth in terms of solutions, but clearly SDK’s and other tools are a integral part of your offering, and a critical part of DX; therefore it’s critical to have a plan in place for managing these as part of your product.

This is most likely going to include monitoring the community – where they are; understanding what tools they want; staying engaged.

Using Structure

Another nice 3 point list was around structure – i.e. allowing people to navigate through the information you provide them:

1. Where am I?
2. Where can I go?
3. Where did I come from?

Telling a Story

Whilst having information in inherently useful structures is good, you can augment this in key situations (such as developer onboarding) with Story Telling – another technique covered in the Universal Principles of Design.

Cristiano cited Pusher as an example of doing this well – the “hello world” make your first app story.  Here’s the screenshots, as you can see the path from account creation to “hello world” has been streamlined, and users can easily opt out of this if they want.

References

• https://betta.io – Cristiano’s website, which includes:
  • “The 7 Sins of Developer Experience” slide deck (generic)
  • Developer Experience Design Patterns
• https://www.apidays.com.au/
• Removing Friction in the Developer Experience: Adrian Trenaman Shares Experience from HBC at QCon NY (2017)
• Cognitive load (Wikipedia)
• Universal Principles of Design (Books)

#ApiDaysAU

Real World Machine Learning with Susie Sheldrick #APIDAYSAU

I’m at the API Days conference, and one of the first sessions of note was Deep Learning: Real World Applications with Susie Sheldrick, which explored some of the practical real-world challenges related machine learning, based on experience.  I also caught up with her after the session where we expanded on some of curlier questions.

Quick Context: 30 Second Intro to Machine Learning

Susie kicked off with a simple diagram that sums up what machine learning is in comparison to traditional applications:

Machine learning partially turns this model on its head: the solution is able to “learn” its own rules (through training its internal rules model) at much greater scale than some person/team coding them by hand.  So, rather than feeding data and manually created rules into an solution, simply train the solution to produce its own rules.

The Chaser

This nice intro kicked off a mental train of thought for me: in practice the more complete solution probably looks something like this:

The end goal is still to build an solution that provides the answers users were seeking, we’re simply using machine learning to help out with the rules.

Devil in the Detail

That all sounds wonderful on paper – or in ivory-tower pixels – but, as should be no surprise, the real world is not so straightforward.

Of critical importance:

• Understanding the problem you’re trying to solve.
• Gathering the right data to train the model.

This is much easier said than done, it transpires that:

• It’s all too easy to inadvertently train bias into the rules model.
• Tracing exactly how the AI made a specific decision actually turns out to be really hard.

Whilst the second point has obvious implications for developers and testers, both points combined have massive implications for your legal teams, anyone who considers themselves ethical (like you, right?), product owners and anyone at the receiving end of a machine determined decision.

Bias

Susie gave some examples of unexpected and undesirable bias ending up in rule models, such as one experiment that determined prisoners eligibility for parole.  It turns out that the model significantly favored granting parole to white prisoners and was relatively much less favourable to prisoners of colour.   In contrast, in terms of parolees reoffending – the actual results were the exact opposite of the bias.

It turns out that the information used to train the model was “correct” but only in the sense that it faithfully transposed the bias already inherent in the legal system, against people of colour.

True Representation

A related issue isn’t so much of bias in the data, but of bias stemming from an absence of data.  Once more issues of race come to the fore; this time it was a passport application solution that told an Asian gentleman his submitted photo “did not meet our standards” because he was “asleep”.  As you might be able to guess, the model had obviously not been sufficiently trained with data that faithfully represented the entire user base, and therefore could not correctly handle non-european facial features.

Just to be crystal clear, the technology is more than capable of correctly handling a wide range of cases, nuances and subtlety – including racially based facial features.  The actual issue is the correct training of the model – meaning it’s critical to gather the right data, data that covers the entire spectrum of cases.  Not to mention testing and monitoring the behaviour of the solution.

Building an AI Solution: Custom or OOTB?

If you’re about to embark on a project that involves machine learning, one of the practical questions you’ll come up against is whether or not you can use an Out-Of-The-Box (OOTB) solution, or need to custom build something.  Susie’s discussion here was mostly in reference to the rule models specifically.  If you want a model capable of identifying cats in pictures online for you meme generator – you’re in luck, but if you need to correctly identify something more obscure, or more specific, you may have to build this model yourself.  Which is why the stuff above about bias is so important, because you’re going to have to navigate that minefield yourself.

Further Questions

Our chat after the session was very stimulating; a couple of the more curly questions that our conversation provoked were:

How to identify, and test for, unexpected bias?

The obvious ethical reaction to all of this is “great, let’s ensure we keep unwanted bias out of the model and our solution”.  What is much less obvious is how to do that.

Were the team behind the parole example conscious of the bias in that solution?  Let us assume they weren’t aware of it – in such a situation how would they (or you) identify that bias, and in addition, having established an operational solution how would you ensure none was introduced?

This is where, for me, machine learning is like a lens that amplifies human behaviours and bias.  It has the potential to help expose them, but how clearly, how soon, and at what cost?

How will your model react in the event of change over time?  I.e. if there is a fundamental shift in the (data) foundations on which the model was originally conceived and trained?

For example, Google is looking at moving back into the Chinese market, despite pulling out some years ago due to human rights concerns.  Hypothetical example: let’s assume that they have machine learning models built up, based on the data they currently have access to – i.e. does not include China’s current population of 1.3 billion.

What would happen if 1.3 billion Chinese people suddenly have access to a Google solution that is backed by a rules model that was not trained with them in mind?  Sure, Google’s data should be a fair representation of their current global user base, which will include Chinese – but wouldn’t adding 1.3 billion people potentially shift the model?  How will it react?  Will the responses it provides be biased against the new user population because hitherto they were not expected by the model?  Will the model be able to adapt over time, and if so how long will that be?

 

Please note that this post is based on rapidly scrawled notes in session and my recollection of subsequent discussions – my accuracy should be reasonable but may not be perfect.

References:

• Susie Sheldrick on LinkedIn: https://www.linkedin.com/in/susan-sheldrick-ba699062/
• API Days official website: https://www.apidays.com.au/