Project: RasPBX (FreePBX/Asterisk) for the Home

In the early days of VoIP, most users were still using analog phones through ATAs and early softphones with services like Free World Dialup (later, FWD) which offered users free SIP accounts that could call within the FWD network for free, as well as limited “interexchange” connections sponsored by VoIP companies that allowed for landline users to “dial in” to a FWD number. Later on, as users began to join various independent voice service providers (VSPs), SIPBroker became a way they could call each other without cost across networks. Unfortunately, this has slowly fallen by the wayside and a number of mappings no longer work. Aside from these services, there was also VoXaLot which offered both paid and free options with even more sophisticated abilities such as making call routing decisions based on dial patterns and media transcoding which allowed me to make calls from a lowly 32kbit/s Unwired connection using G.723.1.

Needless to say, FWD and VoXaLot are both defunct and SIPBroker is looking a little anemic. If you’re still interested in using VoIP with ATAs and making free calls between them, chances are that you’ll have to go with the same VSP on both ends and possibly even pay a fee as “fee-free” accounts are no longer the norm (at least, in Australia).

But there is a better way, namely running your own PBX and the loss of these services definitely inspired me to explore it. In fact, I was already running my own when Project Fax started but I never made the effort to write anything about it. This time, I decided to start afresh with an old Raspberry Pi instead of an x86-64 virtual machine for low-powered goodness.

Why Might You Need a PBX?

As a home user, it might sound strange that you’d even want a PBX in the house. This was something traditionally reserved for a medium to large company, at least, in the older days. But there is a number of good reasons why you might want one:

  • To allow you to demonstrate and experiment with old PSTN gear (including modems) using ATAs as line interfaces without routing your calls out over the public internet or relying on a VSP to handle your SIP sessions or paying your VSP for multiple lines.
  • To run a virtual fax machine based on a hylafax to send and receive faxes without a fax machine over the internet through a VSP, or to local ATAs to test T.38 and pass-through audio capabilities.
  • To allow you to use old handsets as intercoms throughout the house by dialling an internal extension for free calling. You could even replace a doorbell with an old phone – pick up the handset and it rings the phones inside the house automatically (hotline operation).
  • To allow you to share a single VSP account amongst multiple phones (although only one call can be made at a time) without having to enter the VSP account credentials on all your devices and changing it every time you change your VSP. You can even set a password on the VSP trunk to prevent unauthorised use and set up dial patterns so that premium calls are not directed to the trunk.
  • To allow you to use lowest-cost routing across multiple VSPs (or provide route failover) by setting appropriate dial-patterns and trunk orders, so you always get the best call price.
  • To overcome certain NAT problems – get the ports forwarded correctly for your PBX and it will speak to all your devices within your home network free of firewall issues. A difficult situation in you have multiple ATAs trying to register through the same NAT using the same ports!
  • To allow incoming calls on your DID to ring multiple phones – that way you can answer from whichever one is closest and transfer it around the house.
  • To set up call recording so that all calls through the VSP are automatically recorded.
  • To allow you to run your own “hotel-like” wake-up call service and wake up to the traditional ring-tone of a telephone.
  • To allow you to use it as an “arbitrary” audio link for use in relaying radio (which is one of my favourite uses) both inside and outside the house.
  • To provide teleconferencing services allowing multiple-parties to connect together in a bridge call.
  • To perform codec transcoding between SIP devices with incompatible audio codec standards.

RasPBX

The easiest way to get started is to use an “all in one” package of sorts. For most people, this means choosing something like FreePBX or PBX in a Flash (PIAF) for a regular old desktop or laptop. The former is based around Asterisk and an open-source GUI for administration, whereas the latter is somewhat more proprietary being based around 3CX Phone System, both running on Linux.

The equivalent of FreePBX for Raspberry Pi is called RasPBX (or Asterisk for Raspberry Pi). Just like other Raspberry Pi operating systems, you need to download an image, write it to card, plug it in and turn it on. Once running, you’ll have a bit of configuration to do.

Configuration Tips

This isn’t going to be a complete guide to configuration, but will touch on some important points to check with a few hints for common issues. I encourage all users to take the time to familiarise themselves with the configuration options – make a mistake and you could end up with a PBX that could be externally exploited (where you have opened outside ports, allowed anonymous calls, set the inbound context strangely, not set passwords on outbound trunks, set weak secrets on your SIP extensions or administration users etc).

The first step is always to login via SSH and change the default password. Once that is done, then it’s probably a good idea to run raspi-config to expand the filesystem, set the locale, set up any overclocking and reboot. Once that’s done, it’s back to do raspbx-upgrade, install-fax and install-fail2ban.

At this point in time, it’s probably worth giving your device a static IP address. If you’re not going to do this by binding the MAC at the DHCP server, you can do so by editing /etc/dhcpcd.conf and uncommenting some of the example lines while changing the values to reflect your network.

Once that’s done, you can visit the address in your browser and configure the installation like any other FreePBX installation.

Once logged in, there’s a good chance there’s a list of things you need to do. The most important is probably to go to Module Admin, check online for module updates and apply them all by marking the necessary changes and hitting Process. It will take a few goes to fulfill all dependencies. Also choose any packages you’d like to have – e.g. Wake Up Calls for example (although it has an undocumented dependency on Calendar, as I later discovered).

Assuming you’ve gotten this far, it’s time to configure your extensions. Each of your ATAs and softphones will need an extension to register with the RasPBX. In my case, being lazy, I allocated three digit extensions sequentially – there’s no harm in making a few more than you need for later use. In the case of RasPBX, the default type is pjsip rather than Chan_SIP, which results in fewer configurable options but an easier experience overall.

Important values include the Secret, which is the password that the ATA will use to register with the RasPBX. The other password is for access to the user manager, which is not installed by default. You can configure per-user recording and features on the other tabs. Once you have extensions, you’re almost ready to make calls between endpoints!

Of note is that some extra features (e.g. echo test) are available via Feature Codes which can be redefined – this is necessary as many ATAs grab the *xx codes for their own feature code usage, making it impossible to dial these features from a ring tone. As a result, I reallocated the Wake-Up call from *68 to 800 to avoid this issue.

But you probably want more, so setting up conferences is probably a good idea as well. Conferences are numbers where multiple callers can dial in and talk to each other at the same time. However, you can use it as a broadcast as well – in my case, I configured the 999 conference to connect as muted with the conference control menu (*) available to unmute a user manually. The time limit to the conference was removed and a few other settings tweaked.

Aside from having these features, you might also want to set up a trunk. This is a line you get from a VSP, so you can route calls between your extensions and the outside world via these trunks or accept calls from the outside world through these trunks.

In my case, because the trunk is of pjsip type, the trunk name has to match the user ID. Setting it up is a breeze compared to the older Chan_SIP method where a number of voodoo settings had to be tweaked to make it work.

While you might have a trunk set up, it won’t be used unless an outbound route exists, so it’s time to set one up.

In my case, I have password protection on my outbound routes and I’ve configured a group of “Australian” type numbers to be passed through this route to the trunk configured above. Not all types of calls are routed out the trunk – notice the absence of 000, or 19xx numbers. This way, there’s no chance of accidentally making those sorts of calls.

Likewise, if you want inbound calling to work, you need to set up an inbound route too. This could be as simple as forwarding the call to one extension, or to an IVR menu or a ring group.

Finally, it also makes sense to configure the advanced settings just to make sure your addresses, interfaces, NAT settings, analytics settings are correct, as well as to choose the most important codecs you might want to use with your PBX. I’ve gone with a complement of ‘regular’ high quality codecs and some low bandwidth specials.

How I’m Using RasPBX

I primarily use my PBX with a number of ATAs and softphones (including CSIPSimple, LinPhone, MicroSIP and 3CXPhone). The main reason is as a way of distributing the audio from my DMR digital radio trunking set-up to wherever I might be listening. Instead of using an old-hat system such as running my own ShoutCast/ICECast server, I decided to go the VoIP route for a number of reasons – radio voice is inherently “low-fi”, such streaming servers incur high latency due to the compression and buffering as well as less-than-preferential treatment on the network due to being a non-realtime protocol and by using a VoIP based solution, I can use some older telephone equipment as part of the system as well.

In order for this system to work, I use the “999” conference which is muted by default. The computer that is decoding the DMR audio loops the output back into a softphone registered at extension “100” and dials 999, followed by * and 1 to unmute and send audio into the conference. As 999 is a conference, all other extensions are free to dial-in and can simultaneously receive the audio.

When around the house, I can use this Uniden DECT 1015 that I modified as my receiver. I desoldered the leads to the earpiece and connected it to a stereo 3.5mm socket with a 100 ohm resistor in series. I also soldered a bridge across the microphone, shorting it out, preventing “side-tone” and “hybrid mismatch” interference from the microphone pick up.

Because the battery in the unit had been roasted, I replaced it with a 2xAAA holder initially and cut off some of the pegs inside to make it fit. Unfortunately, the holder itself became faulty, so I soldered to the batteries directly and heatshrinked around it to rebuild the pack. It has been working well since with about 6-8 hours listen time on a charge! This way, I’m clogging up the DECT 1.8Ghz spectrum rather than my own Wi-Fi.

To ensure the best quality, the ATA (a Cisco SPA112) is configured to use G711a as the codec and is configured to “hotline” into the 999 conference – so all I have to do is pick up the phone and I’m on.

Just in case you’re wondering – there’s a few more settings worth tweaking for that “genuine” Australian phone line sound.

While I’m at my desk, I have a proper PC and I can connect to the stream via MicroSIP registering on another extension. Better yet, as the receiving computer has VNC control, I can even check the screen to determine which talk-group is active.

But the best part is when I’m not at home. There’s no way I can carry a laptop, two tuners and antenna around just to listen to some DMR, so instead, now I rely on the internet to link me back home to my set-up. That way, I can be out and about with my phone and look like anyone else on a phone call … but I’m actually scanning the air.

To do this, the RasPBX has been configured with a trunk to my VSP. As I still have $0 monthly accounts with my VSP and my VSP allows free calls between internal VSP numbers, I register my smartphone to my VSP when I am out and dial the VSP trunk number. The inbound rule routes it into the conference automatically and I’m listening on the go. Better yet, as I have another Raspberry Pi configured as an SSH tunnel – I can even get back into the home network to view the VNC screen if necessary.

This is, however, a simplified explanation, as I am relying on a triple-NAT to WAN which I cannot do anything about. While it’s much safer to “hide” behind your VSP and not expose your asterisk server to the world, it’s also a bit of a chore to make sure it works reliably owing to the complicated mechanics of NAT traversal (especially multiple). Luckily for me, it seems to work just fine – but for my SSH tunnel, this actually relies on me reverse-tunneling to my other house with a static IP and no such NATs in the way.

If I were just to end it here, having the audio would probably send me broke owing to the fact I’m paying LTE data rates on both ends, so this is where wise choice of codecs comes in. Because of computational limitations on the Raspberry Pi and codec support limitations, I settled on Speex as my preferred low-bitrate codec due to its quality and configurability, with iLBC coming second due to its high packet-loss tolerance and GSM coming third due to its broader support.

While there is no /etc/asterisk/codecs.conf in the distribution, I found that if it is created, the Speex encoder will use it!

[speex]
;0-10
quality => 3
;0-10
complexity => 8
; true / false
enhancement => true
; true / false
vad => true
; true / false
vbr => true
; 0 = off, otherwise, target bitrate in bps
abr => 0
;0-10
vbr_quality => 8
; true / false
dtx => true

[plc]
; for all codecs which do not support native PLC
; this determines whether to perform generic PLC
; there is a minor performance penalty for this
genericplc => true

I decided to tune the configuration from an initial suggestion from this page. The tweaks improve the encoded voice quality at the cost of CPU (since lowering bandwidth is the aim) and enable VAD (voice activity detection) and DTX (discontinuous transmission) to allow for large bandwidth reductions when no audio is being sent. This is not something which other codecs seem to do with asterisk, even if the incoming audio to a conference is from a VAD source. Enabling VBR causes the bitrate to be allocated flexibly, which means overall better voice quality for the same data transacted and enhancement further provides a perceptual quality boost.

As a result, using CSIPSimple on my smartphone, it’s actually quite possible to have a 45 minute call consume around 4.11Mb of data, averaging 4.7kbit/s of payload for the audio with 11.1kbit/s including overhead. The transmitted audio consumes <1kbit/s due to the use of VAD in the softphone client and muting of the microphone. Add to this the ability to connect a Bluetooth headset so you can enjoy radio even more wirelessly!

Now you can have decent quality voice on the go without breaking the bank! It’s rather impressive that this is even possible, although there are a few downsides including the “irregular” data rate can cause occasional stuttering as the network struggles to meet “peak” demands or NATs start to act strange in regards to packet buffering. I have a second configuration I use with VBR turned off, which seems to behave slightly better in these regards – but even at home on the Wi-Fi where bandwidth is no issue, I still prefer Speex as it reduces network load and power consumption of the Wi-Fi radio in the phone.

Conclusion

There’s a few reasons why one might want a PBX of sorts for their home and in all honesty, it’s not that difficult to set one up. It can be rather useful for experiments but also for intercoms, conferencing, wake-up calls and arbitrary real-time audio linking.

In my case, I’ve used my system extensively to provide “at home” and “on-the-go” linking to my DMR trunked audio decoder and it has worked brilliantly with low latency and bandwidth consumption while mobile and transparent quality while at home. It’s a rather strange feeling when you’re sitting on the bus and you hear a transmission over the driver’s radio – all tinny and a little scratchy, but less than two seconds later, you’re hearing it crystal clear through your own headphones! Yet, nobody suspects a thing – it’s not like carrying a chunky radio scanner.

Later on, I will be using the same system to do some telephony demonstrations for fun as well, so having the RasPBX available means having the convenience to do rather nifty things without burning through a lot of electricity.

Posted in Computing, Radio, Telecommunications | Tagged , , , , , , , | Leave a comment

Opinion: The ‘Secret’ Life of Bus Drivers

As a frequent public transport user, I’ve always had an interest in various modes of transport. By far, the one that has proven to be most entertaining to monitor in recent times has been that of the bus radio, as they rely on their radio a lot for operational needs. This means that there’s always traffic to listen to and you’re always kept up to date as to what’s happening in the buses and on the roads in the area. As someone who had listened to the State Transit Authority (STA) or Sydney Buses radios for many years in the FM days and recently transitioned to listening to DMR over the Orion Network, I’d have to say that even though a few things have changed over time, many things still remain the same.

As the hobby of scanning seems to be somewhat less popular than it once was, I thought I’d condense my many hours of listening and observing into an opinion article. This way, ordinary day-to-day people might have a better appreciation of just how complicated it can be to be a bus driver operating a bus or a dispatcher in charge of a whole fleet of them. Maybe then, bus users can appreciate just how much of a miracle it is when the bus it on time for your trip and how much effort is put in to ensure everyone has a safe trip. It also gives me a chance to introduce readers to some “bus driver lingo”, which does vary from company to company.

As a disclaimer, I have not worked as a bus driver, bus dispatcher nor have any direct connection with the industry. The views presented are based on a mixture of publicly available information, observed radio transmissions over a number of years of listening and informal conversations with local bus drivers during their down-time waiting for timing points. When your perspective comes from listening to the radio, it is definitely skewed towards buses experiencing issues as every bus that’s doing just fine is not going to be on the air. In that regard, quoted transmissions are based on transmissions heard on the air, with company/shift/run/fleet numbers replaced by dummy names.

The Protagonists

A bus company has a lot of employees, but when it comes to day-to-day operations, the most important groups of people are probably:

  • The Depot Manager – rarely heard on the radio but occasionally called “yard”, but they are in charge of directing a driver to where to find their particular bus (identified by the “bus number” or also known as “fleet”) or where to park their incoming bus.
  • The Dispatcher – depending on the company, this could be called “Control” or “OCC” (short for Operations and Control Centre). This is one of the most important people in keeping operations running to schedule and does almost half of the talking on the air. In the evenings, some companies close down their control centres, resulting in a handover to “depot”.
  • The Driver – of course, every bus that needs to do a run needs to have a driver …
  • The Mechanic or Workshop Staff – depending on the company, there are “mobile mechanic” units ready to dispatch for emergency minor repairs on the road and a workshop at the depot to undertake more serious maintenance tasks.
  • Other Drivers and Road Users– as the bus system is a “network” with shared facilities, inevitably, every shift will have to come into contact with other drivers, sometimes even from outside of your own bus company. This also includes other road users – more about that later on.
  • The Shift Manager – allocates upcoming shifts to drivers, including “run sheets” (or decks/cards) which detail which trips need to be made and keeps a check on the number of hours each driver is doing for fatigue management.

So, You Think You Can Drive?

Imagine yourself to be a bus driver. You were told you have a shift early this morning, so you made your way to the depot at 5am in the cold winter weather to get going. It might be frosty and you might have had a late-night last night because of some limited overtime, but everyone is relying on you to do your bit and get them to work, school, university, etc.

You get allocated a shift and a bus, so you trudge out to the depot to grab it. The buses have had a hard life – they drive countless number of kilometres a day and sometimes it shows. You hope you get a better bus, but at this point, a bus that works is probably better than nothing.

Most of us might imagine starting a shift is as simple as hopping in, turning the key and driving off as you would in your own car, but for a bus driver, there is a procedure that needs to be followed. This is to ensure everyone’s safety and comfort. The checklist includes checking the bus’ mechanical condition – does the bus drive well, steer well, brake well, are the belts in place, is the oil level and coolant level good, is the fuel level sufficient, do they tyres look fine and is the body in good shape. Then, they have to take care of other things like looking around for lost property, strange items, sweeping down the bus to clean it up. At this point, if you find a dirty bus that you have to clean, you might just feel grumpy enough to put in a report:

Driver: BusCo Control … Ah … it seems that whoever had Fleet 1234 in the last shift yesterday didn’t clean the bus and I’ve got to clean it now. Can you write up a report about this?”

Dispatch: “Copy.”

After the bus has all major faults rectified and is ready to depart, it is customary to call-in to let the control centre know that you’re heading out and as a check that the “two-way” radio is working. This is when you might hear:

Driver:BusCo Control … Shift 123 Zulu in Fleet 1234 leaving the depot now. Running five minutes late due to low coolant which I have topped up and dirty bus.”

Dispatch: “Copy that 123 Zulu, running five minutes late. Have a good shift.”

At last … you’re on the road heading towards the first run.

Running a Shift

A shift is made up of a number of runs, normally listed on a run sheet/card/deck (depending on the company). This details which route is to be run, which timing stops on the route need to be adhered to. Running a shift is, in theory, as simple as following each of the runs on the sheet and then returning back to depot. In reality, things are anything but this simple.

If anything, the run sheet is merely an “ideal” that can only happen when all the stars align. Far too often, factors both inside and outside your control can conspire to ruin the best of plans, so any run sheet is subject to almost continuous variations. If there’s one quality I think bus drivers have – it’s flexibility, because when you’re actually getting off work is probably not what’s written on that card.

What follows is practically a list of “101 things that can go wrong on your shift” and consequently, spoil your day.

En-Route Disasters: Human Errors of Varying Magnitudes

It’s no big stretch to say that humans are imperfect, but necessary in many cases. Bus drivers are humans, as are most road users, so inevitably someone might make a mistake. Sometimes, these mistakes can be a small inconvenience, other times they will have a devastating effect. A sample of these human errors that I’ve heard include the following:

Scenario 1: You make a run and nobody gets on …

Everything is swell, you’re on time, you’re hitting all your timing points and breezing through your trip. You get to the terminal stop at the other end to prepare to run the next run on your shift when … *insert dramatic music* … you discover you’ve set your desto incorrectly!

For those who don’t know – the desto is the indicator at the top of the front of the bus (and optionally sides and rear) which indicates which route and direction the bus is taking – get this wrong and of course, passengers won’t get on!

In this case, you sheepishly pick up your two-way and report your error to control, who takes a look and decides there’s nothing which can be done – it’s too late to re-run the service, so you’ll just have to continue on. But this will definitely haunt you for the rest of your shift.

Scenario 2: You make a run, but you didn’t login to the correct run on the console …

Although unlikely, there has been cases where drivers started a run but didn’t log-in correctly on their console. As a result, real-time bus tracking is confused about whether you’re running early or late and sometimes, it means drivers have to manually select their stop to enable the bus reader.

Sooner or later, dispatch calls you up on the radio to check as you’re not tracking on their console … but if they don’t, then it’s yet another embarrassing mistake you’ll have to own up to sooner or later.

Scenario 3: You mis-read your run sheet and you made the wrong run!

Expectations play a big part in human psychology, so if you’re always driving Shift 123, you’d expect your run card to be the same as yesterday, right? But someone’s decided to play a game and now there’s a slight change to your shift … but you didn’t notice!

I’ve heard a few cases when a driver is tailing another bus on the same route on an every-stop basis and decided to radio in to ask “if they’re running late or very early or doing the wrong run”, and only then, was it rectified by either transferring passengers and cancelling one, or running set-down-only followed by an express to the next run location. In other cases, the driver didn’t notice until they reached the end of the route and the next run was in a completely different and distant location.

Scenario 4: You make a mistake en-route and miss a few stops.

While you might expect most bus drivers to be highly experienced and know the routes like the back of their hand, the truth is that there is quite a bit of churn in the bus driving occupation which means there is always a new driver or two. Aside from that, there’ll always be a few drivers who might be a bit tired and forgetful, so even with the “route hint” markers on poles, it’s not uncommon for a driver or two to miss a turn.

Once the driver realises this – maybe because a passenger bought it to their attention, then they’d have to contact dispatch to determine how to rectify this. Other times, dispatch may have been tracking and found that the bus was reaching stops earlier than expected and will radio the bus for a confirmation. Often, if the bus isn’t too late, the driver will be asked to circle around and revisit the missed stops to make sure nobody is left behind.

Scenario 5: You get lost … like, really lost.

This is another scenario that is more likely to happen with newer drivers, with road diversions due to roadworks or at night. Somehow, maybe between runs or even while en-route, you miss a turn and now you’re completely lost.

If you’re driving a car, this is no big issue, you can just park the car, take out your phone and pull up your maps app and get going again. But for a bus driver who is not allowed to use their phone while driving, with a bus that is so large that it’s not possible to easily park, reverse or turn the bus around, this can be a big issue.

As a result, now you’re completely reliant on your radio dispatcher to get you back on track. They do have GPS tracking, but sometimes it’s delayed, so they might ask you to turn at a given street but you’ve just passed it. Other times, they don’t have this visibility and you have to instead rely on your general knowledge of the area to ask whether a certain route is viable. The dispatchers (and other drivers) are quite patient and want you to be back on the road as soon as possible, so they will walk you through as much as possible and chime in with local knowledge – but they can’t help it if the radio is scratchy and have to attend to other buses too. If all else fails, they’ll ask you to see if any passengers can help … that’s got to hurt. More than that, your other runs might need to be handed over to others, so that they aren’t cancelled or run excessively late.

Scenario 6: You get into an accident of some sort.

Statistically speaking, if you’re on the road, you’re probably going to get into an accident sooner or later. It might not be your fault at all – silly drivers overtaking turning buses or cutting them off are a constant menace, but as soon as any body panels make contact, you know that a can of worms has just been opened.

The most obvious response is just to check that everyone on the bus is okay, to exchange details with the other driver as per protocol, to assess the situation with the bus as to its driveability and radio the accident information to dispatch. The downside is that most of the bus drivers probably heard your report, so you’ll be teased over the radio for a while to “be careful with the bus” and “don’t damage this one.” But don’t worry, they’re only poking fun at you. But if the bus is undriveable, then the depot will probably get involved with a changeover bus, bringing a mechanic to fix and/or ferry the damaged bus back to the depot. As long as you’re still in a condition to drive, the shift carries on, but now you’re running quite late and there’s a mountain of paperwork awaiting you when you return to depot.

While the majority of the above can be classed as your fault, there are just as many (if not more) situations which are not under your control which can make things

HALT! Rendezvous and Timing Points

A number of runs in the day are special – this can include “split” routes where part of a service is driven by one driver which meets another bus and driver at one of the stops and transfers their passengers across (a “head-off” situation). Another is certain routes which may be advertised to connect with other routes (a guaranteed “transfer” situation).

As a diligent driver, you might be running on time and have reached your transfer point. Unfortunately, the other bus you’re receiving transfers from is nowhere to be seen!

Driver 1: 123 Zulu to BusCo Control

Dispatch: BusCo Control receiving. 123 Zulu, go ahead.”

Driver 1: 123 Zulu is at the transfer point. I want to know if there is any transfers?”

Dispatch: 123 standby, BusCo Control to 456 Zulu.

[ Long Silence ]

Dispatch:BusCo Control to 456 Zulu.”

[ Long Silence ]

Dispatch:123, I couldn’t get a response so can you just please hold for a few minutes.”

If you haven’t worked it out already – you were on time … and now you’re not! Maybe there’s a two-way coverage issue or the other bus driver isn’t listening attentively, but until an affirmative response is received or the transfer bus is met, you cannot depart.

Driver 2: 456 Zulu to BusCo Control, were you calling me?”

Dispatch: “Yes 456, 123 wants to know if you have any transfers?”

Driver 2: “Ah … I have one transfer on-board, I’m five minutes down.”

Dispatch: “Copy that 456, 123 please hold, there is one transfer for you.”

Driver 1:[Begrudgingly] Copy that.”

With those words, you’re stuck for another five minutes. It’s probably not the end of the world, but when it comes to buses, just a few minutes can make all the difference. It’s like a snowball effect – run a few minutes late and you’ll end up picking up passengers which may have boarded the next service. This makes your bus fuller and lengthens your dwell time to accommodate boarding and disembarking. In turn, this makes you even later. You just can’t win!

Some drivers, noting this, must have been a little sneaky in the past thinking they can catch up if they just don’t pick up along the way. This has led to the introduction of automated radio announcements –

Dispatch: “OCC to all drivers. No driver is to run set down only or limited stops without OCC’s prior approval. OCC out.”

Of course, you can have the exact opposite problem. A low patronage route with no such transfers and no one to pick up is sure to be one where you could conceivably run early. The problem is that this is not allowed either. Run early and you risk leaving behind legitimate customers who can and will lodge complaints. As a result, at specified stops along the route termed timing stops, a driver must adhere to a published timetable on their run card. Unfortunately, some passengers who are none the wiser often get annoyed while sitting on a bus that’s not moving and not picking up anybody – not understanding that this is a necessary operational requirement.

As a result, running a route correctly is a game of being always on (or close to) time to a schedule developed by a routing team, in the face of many variables outside your control. Early or late, there will be consequences either way. Lucky for you, you’re not the only driver out there and the control centre has some resources they can use to make up for a few unexpected issues.

Unexpected Guests: Bus Rage, Drunkards, Oversized Items and Fare Evaders

While a bus driver’s job can be summarised mainly as to convey passengers around a pre-set route, unfortunately, passengers don’t give them (or the rules) much respect. Passengers will often talk loudly on their phones, listen to music in the open, bang on windows from time to time and eat or drink on the bus contrary to the rules. This is an inconvenience to everyone on the bus and can make a bus journey miserable for all.

But even more than that, bus drivers are frequently the victims of abuse from passengers – this can range from verbal complaints of late running, confronting drivers with cell-phone cameras and verbally abusing them, through to physical abuse in spitting or throwing punches, to even (at one stage) pulling a gun on a driver. Under these circumstances, it’s easy to feel like you’re doing a thankless job – every bus driver wants to be on time, but often if they’re late, it’s not their fault. There are rules as to maximum driving time, minimum rest periods and lunch breaks. If they’re late on one run, they may (without other assistance) have to run their next run late, which could snowball into an even bigger issue. If it is severely late, the company may opt to provide free-rides but that rarely quells the (arguably misdirected) anger of the passengers.

I term this type of aggression and disrespect “bus rage” and in this area, some buses have been equipped with full size cages to try and better protect drivers against it. This is especially the case late and night where some commuters may have chosen the bus as their Plan B and are inebriated to an extent that they just cannot control themselves.

Driver 1: “I have a passenger on my bus and he seems to have passed out. I can’t seem to wake him. He smells like alcohol. What should I do, control?”

Dispatch: “Copy that. If you can try again to wake them, maybe get a passenger to help and remove him from your bus. Do you need police assistance?”

Driver 1: “I will try again … if not, then we will need the police.”

Driver 2: “Watch out, he might wake up swinging.”

Driver 1: “Thanks for the warning.”

Dispatch: “Copy that. Let us know if you are able to remove the passenger from the bus and their description so I can pass it to the police for patrol.”

As a result, being a bus driver is more than just driving a bus – passengers like this can hold up the bus, so a driver has the impetus to eject them from the bus to keep the service going for all. They have to make snap decisions and possibly put themselves at risk (of a punch) to ensure the passenger disembarks where they intended to – sometimes by assisting them off the bus. But sometimes, it can’t be helped …

Driver: “Uhm … Control, I have some liquor spill in my bus.”

Dispatch: “I didn’t copy, could you please repeat?”

Driver: “Control, a passenger spilled some liquor in my bus.”

Dispatch: “Copy that. How big is the spill and do you have any passengers on your bus?”

Driver: “The spill is from the rear doors of the bus right up to the front. The floor is wet. I have two passengers, but I am still on my run and might pick up around five. Over.”

Dispatch: “Copy. I’m just looking at the options, but for now, could you just run the bus and advise passengers to take care as there is liquid on the floor. You’d hate for a passenger to slip. I’ll look for a changeover for you when you arrive at Fictional Terminus.”

Other times, there are altercations that break out on the bus which can result in a bus being held as police are dispatched, resulting in a long wait. Worse still, if bodily fluids (e.g. blood, vomit) is spilt on the bus, then the bus is taken out of action for a changeover. This leads to services running late, cancellations and drivers needing to transfer passengers and set themselves up on another bus, while another driver going off-shift ferries the soiled bus back to the depot.

It can get fascinating at times when people use the bus for unintended purposes. One exchange went like this:

Driver: “Ah … Control, I have a passenger who wants to move a bed frame. Is this okay?”

Dispatch: “Was that a bike? You can carry a bike at the driver’s discretion.”

Driver: “No no, a bed frame. Over.”

Dispatch: “Was that a B-E-D frame?”

Driver: “Yes.”

Dispatch: “Oh gosh, no! Definitely not!”

I can understand this to some degree, as some people have no other forms of affordable transport to rely on, but being unreasonable and arguing with your bus driver about it is only going to make the day worse for everyone. Everyone possibly except me – as I had a chuckle.

Another issue is fare evasion. A bus driver has to collect fares from the passengers – for one operator, they remind them periodically with an over-the-air broadcast:

Dispatch: “All drivers. Standby for an announcement from OCC. All drivers are reminded to ensure that all passengers, including school students, tap on their Opal cards. Have a good shift. OCC out.”

For people with Opal cards, this means ensuring that they tap their cards on when getting on the bus. For those without sufficient balance or no Opal card, this means issuing regular thermal-paper tickets. Unfortunately, there is a small minority who decide that the bus is theirs to ride without paying and while a driver can ask the passengers to tap-on or to pay, if they do not co-operate, short of delaying the bus for an unreasonable amount of time, all they can do is “report a Code Two”.

Driver: 123 Zulu, two Code-Twos at Fictional Stop.”

Dispatch: “Copy that.”

This helps them record the lost fares from where fare evaders are boarding and provides information for revenue protection officers to perform enforcement activities.

In other cases, as a heads up to other drivers, broadcasts might be made:

Driver: 123 Zulu, to all following route XYZ drivers. There is a group of six people at the corner of Fictional Street and Fictional Road. They tried to board my bus but they have no money on their Opal cards and they have no money. If you see them, you do not need to pick them up. Over.”

Error 404: Bus Stop Not Found

So far, we’ve dealt mainly with the logistics of going about the route, but what about the stops themselves? There are a number of potential issues with bus stops that cause tension between bus drivers, road users and passengers.

The first is that the bus stop itself does not exist. Drivers are not permitted to pick up and set down at places other than designated bus stops for the safety of passengers. If the stop does not exist due to an infrastructure issue (missing signs), recent changes to the route or due to temporary relocation, a driver should not pick up or drop off passengers. Passengers who think they know better often argue with drivers, to which they may end up relenting, but this places the driver in a legal situation if anything were to happen and could also put the driver at risk of complaints, as such manoeuvres may result in illegal double-parking.

Another is that the bus stop is blocked from access – this can be due to other vehicles illegally parked in “bus zones” or illegally using bus-only lanes. Unfortunately, where a bus stop is inaccessible, the driver doesn’t have many legal options (aside from sounding their horn a few times and possibly flashing their lights) but to move on to the next legal stop. This is inconvenient for passengers, but a driver has no other form of control. A lot of illegally parked vehicles either misunderstand or deliberately disrespect the signage and will come out swinging – recording registration numbers, getting video recordings of the bus driver when they are clearly in the wrong. Others just believe that having the hazard lights on is a license to park “anywhere”.

Sometimes, bus stands at interchanges are clogged by an excess of bus arrivals including buses from other companies, which can result in delays. For passengers looking to connect with other transport services, this can be quite frustrating but your driver can’t do much but pick up the radio and report the issue – but this may just mean that the driver has to fill in a form at the end of the shift but the situation isn’t improved.

Having a “Mechanical”

It’s no secret that the buses on the road have mostly done a hard life with many kilometres under the clock. Through no fault of your own, you can have a mechanical fault that requires radioing in for advice, speaking to the workshop, proceeding with caution or getting a “changeover bus” entirely. A common line of troubleshooting is merely to shut down the bus, isolate the battery for a few minutes, reconnect and restart – just like you might with a computer.

Common mechanical faults include:

  • Door faults – due to interlocks with the accelerator, a door fault can lead to a bus that cannot be driven. As the sensors are sometimes flaky, massaging the door rubbers is sometimes a “temporary” remedy. A faulty door that flaps about is also a safety issue, so these might be prime candidates for a changeover.
  • Loss of fluids – loss of engine oil pressure due to a leak and loss of coolant are fairly common which normally leads a bus to drive “like a dog”. These conditions can lead to further damage, so these are prime candidates for roadside mobile mechanic assistance.
  • Loss of air pressure – could be due to a faulty brake line or compressor, but since brakes are air activated, a loss of air pressure forces the brakes to be continually applied, holding the bus in position. If it cannot be rebuilt by revving the bus in location, then assistance from a mechanic will be required.
  • Blown airbags – on buses with air-based suspension, blown airbags leads to a bus that will not level, bottoms out and possibly loses air pressure.
  • Punctured tyre – probably due to road debris or running off the road.
  • Flat battery – normally discovered in the morning at the depot, often results in the bus taken out of action if a jumpstart is not available.
  • Various warning symbols and codes – more modern buses with ECUs may generate rather cryptic error messages which are transient.
  • Opal system console becoming unresponsive – sometimes due to connection problems between the machine and pedestal, other times due to wiring problems within the bus. Often results in free rides.

Some less-common faults heard included seat retention system failure, loss of headlights, weak brakes, heavy steering, overly bright instrument cluster lights and radios which were “one way” rather than “two way”.

Failures which affect safety will often require the bus to be changed over, or driven cautiously to the depot by the driver (as long as they are willing) for further repair. A loss of “two way” communications often leads to alternative means of contact – say via the drivers’ mobile phone or relay via another bus radio from a driver parked nearby. Regardless of the fault, drivers need to fill in a “defect” with the bus when they return to the depot.

Jam: Nice on Toast, but not on the Road!

While I touched on the fact that the traffic is a variable, traffic jams are not as simple as they seem. They are rarely predictable and even though the dispatch controller gets both real-time traffic information and information about roadworks and diversions in advance, there are so many variations due to accidents, burst water mains and other issues that often the drivers are left to deal with the issue as it arises. The least problematic is usually spotting a kangaroo, emu or cow on the road, as is heard from time to time.

Many times, a jam is caused by an “MVA” – short for Motor Vehicle Accident. Rubbernecking is a constant problem, slowing down traffic in the area, along with obstructed lanes. As long as the delay is not too bad, often this just means a given run will be held up and be late. But if it gets bad enough that police get on site for traffic management, some diversions could be put into place. A vehicle breakdown in a bad location, or even trucks queueing to enter a depot have caused delays.

In other cases, there might be roadworks for various reasons or road closures for police operations. The result is much the same – a diversion may be put into place.

It may not be entirely obvious, but a diversion is not trivial to a bus. For one thing, a diversion could result in bus stops being missed. Another is that a diversion could send buses down roads they are not permitted to run in, due to weight limitations or because they are just physically too big to manoeuvre around turns or other “road features”. Whether the diversion rejoins the original road in a safe way is yet another concern.

As a result, any diversion often results in the control being contacted to verify directions and broadcast a consistent diversion for all following buses based on a consideration of all the factors. Unfortunately, sometimes the ground crew doesn’t get the message and may continue sending buses down inappropriate routes – resulting in tension between drivers and control. But the drivers and their reports are highly valuable to the dispatchers – they know the road condition around them in the most precise way.

Another common cause for a traffic jam is malfunctioning traffic lights. While we take it for granted that they operate in a co-ordinated manner to efficiently move traffic, as soon as a set of lights begins to “short-phase”, this leads to traffic banking up and drivers sitting for 10-20 minutes “inching” forward at a snail’s pace. Believe me – bus drivers realise how important being on-time is, and they make their frustrations known on the radio.

Meal Time, Crib Break and the “Facilities” (or lack thereof)

By now, as a driver, you might be hungry. In many interchanges, there is a meal room and toilets for the use of drivers, which is shared amongst a number of drivers. There is also a “meal rank” which is a specially designated bus parking lot for drivers who are going on a meal break.

But even this isn’t as simple as it sounds.

Dispatch: “Broadcast to all drivers at the meal rank at Fictional Interchange. If you are due to finish your meal break within the next 8 to 10 minutes, please move your bus to the stand. We have drivers waiting for their meal who cannot park their bus. Control out.”

Driver: 123 Zulu, just reporting that the drivers’ facilities at Fictional Interchange have been vandalised, probably by another driver. The soap dispenser is on the floor and there is no soap in it. Over.”

Dispatch: “Broadcast to all drivers at Fictional Interchange. I have been informed that RivalBus has had a cash tin stolen from one of their buses, so if you are taking a crib or a meal, please secure your bus and lock the doors before leaving the bus. Take all personal belongings with you. Control out.”

As you can see, even just getting a spot to park for a meal break can be an issue. While timetable planners likely plan to avoid crowds, delays due to traffic conditions can result in bunching which results in drivers taking a late start to their lunch. More than this, they have the basic facilities to share between drivers of other companies, but even that isn’t a guarantee they will be serviceable or taken good care of.

Because of fatigue rules, breaks which are taken (crib and meal) must be of a minimum set length, so if one starts their break late, they may have to start their next run late as a consequence to avoid breaching their “hours” which might result in disciplinary action. The dispatchers are kept informed about actual “off time” and “on time” to ensure break durations are correctly recorded and the system will prevent drivers from taking excessive overtime to ensure safety. In some cases, a driver which is “borderline” may have to stop and take a crib even on their final “express” run to the depot.

The Shift Switch-a-Roo and the “O” Word

This part should probably be titled “OCC/Control – the superheroes”, as you might not realise just how vital the dispatch role is to the successful operation of bus services throughout the day. In fact, dispatch operations are extremely flexible and resourceful in allocating the available buses and drivers which actually results in many variations on the printed run cards happening – this is naturally a result of the unpredictability of the roads, the passengers, drivers and buses. As a result, drivers have to be almost equally flexible to be re-dispatched and have their plans changed at the drop of a hat.

If you haven’t worked it out already, the “O” word is overtime. Life as a bus driver is full of twists and turns, so making yourself available for overtime and taking it on is almost an expectation if the whole bus network is to operate effectively. It keeps you “on the road”, keeps the services running to time, keeps the commuters happy and helps your colleague who might be stuck somewhere running late. In return, however, when you vary your shift to take on a run from another shift, you might not be able to continue on with your original shift, so you might end up swapping shifts with someone else or have one or two of your runs covered by others before returning to the original plan.

So how does this dynamic dispatching work? Here’s some examples:

Example 1

Driver: 123 Zulu, arrived at Fictional Interchange. Is there anything I can assist with?”

Driver: 123 Zulu, completed run 007. Can I return to the depot?”

In this case, it’s peak time in the afternoon and buses running late is an unavoidable issue. As a result, the company has decided that any driver arriving at Fictional Interchange should radio-in to offer assistance for overtime. Even the latter request is taken as a check as to whether there is any outstanding work to be done, or whether the bus is “free” to return to depot and end their shift.

Dispatch: “Copy that 123. I’m going to need you to run a short 789 to FictonalTown for 456, starting 1555 from Fictional Interchange, 1620 at Fictional Servo, 1625 at Fictional High ending at 1635 at FictionalTown. Call me when reaching FictionalTown, I’ll look at getting your next run covered.”

The dispatcher has identified that shift 456 is running the latest and needs immediate help with a route 789 service that is going to depart from Fictional Interchange soon. The timing points are passed over the air, with shift 123’s next run to be done by another driver instead. Once the driver arrives at FictionalTown, they are to radio in for their next job. The driver reads the job back to the dispatcher and confirms accepting the job.

Dispatch: 456 Zulu, we have your next run covered. When you arrive at Fictional Interchange, you’ll be my standby. Call me upon reaching Fictional Interchange.”

In this case, the dispatcher lets the driver of shift 456 know that their next run has been taken care of, so they don’t start the run late. Instead, the driver will be the “standby” to cover the next run that is running late and needs to be covered out of Fictional Interchange.

Example 2

Dispatch: “Copy that 123. I’m going to need you to head-off a 789 to Halfway Point for 456, starting 1555 from Fictional Interchange, 1620 at Fictional Servo, 1622 at Halfway Point. Transfer passengers and special back to Fictional Interchange for your next run.”

In this case, instead of being told to take up a whole run, 123 is asked to run part of the route up to Halfway Point, transfer passengers over and go back to the interchange for the next run. This is normally coupled with an instruction to the other shift:

Dispatch: 456 Zulu. We’ve got your next run covered up to Halfway Point. At the end of this run, express to Halfway Point, transfer passengers and head off the run from there.”

By doing this, hopefully enough time can be saved for 456 that they can continue on their original run card schedule by utilising a gap in the schedule of 123 to do the pick-up for the first half of the route and transferring those passengers over.

Example 3

Driver: 456 Zulu, to Control, are you tracking me?”

Dispatch: 456 Zulu, we are tracking you. You’re running 8 minutes down. Unfortunately, we don’t have any resources that can help you out, so you’re going to have to start your next run late. Instead, I’ll help you on the run after.”

Drivers need to report into control once they reach a certain level of late running (6-8 minutes from memory) and this is often done by drawing their attention to the bus tracking so they can get an appraisal of how late they are running versus the timetable. Sometimes, things don’t happen so smoothly – there might not be any spare buses that can take a variation for overtime, so then dispatch is powerless. In this case, they will permit the driver to start the next run late and get the run after covered. Sometimes that’s the best that can be done, especially when special events occur.

As a result, drivers may start off with a run card, but only get half-way before they start to be allocated to helping others out. The importance of the radio and dispatch having visibility and an understanding of the performance of all the buses cannot be understated, as without the dynamic dispatch ability, shifts which run late will only continue to get later and passengers would be adversely impacted. By covering such runs by drawing on drivers who might otherwise have “gone back to the depot” or had a “gap” in their run cards, the quality of service is improved. Passengers might not even realise that the driver and bus wasn’t the one that was originally scheduled. It’s quite logistically involved to be tracking a fleet of hundreds of buses and ensuring they’re all running as close to time as possible.

Another thing that can happen over the radio is that shifts for upcoming days are allocated with verbal allocation and confirmation happening throughout the day. As a result, a bus driver has to be pretty sharp about their plans, dates and times to decide “en-route” whether a given shift is to be taken or “kept rolling” to another staff member.

Meeting Special Needs: School Children, Elderly, With Children, Disabled and Lost Passengers/Property

When it comes to bus patrons, there are a few classes of users who are “special” in the sense they rely on the bus as their absolute mode of transport. One of these are school children – too young to drive themselves, they rely on the bus to get them to and from school on time and safely. As a result of this, school runs are especially monitored for time, with drivers being constantly told if they have “left a child behind” and ordered to circle back to pick them up. Likewise, school bus to school bus transfers are also carefully managed to ensure that they get to their destination with almost no chance of the connecting bus being allowed to leave even if the inbound service is late. This makes running school bus routes extra onerous, although sometimes an unpleasant experience owing to the rebellious, energetic and loud nature of school kids who may refuse to tap on when boarding and cause a ruckus on the bus.

Elderly passengers often rely on the bus as the only form of transport as well. They often take longer to board and disembark and due to their frailty, are best waited upon until seated before driving off. While elderly passengers form an important part of the userbase and drivers are often extremely kind to ensure that the bus is kneeled to the kerb (where possible), it can be a challenge nonetheless for passengers to safely disembark. In a number of cases, an elderly passenger had a fall upon disembarking the bus, causing the bus to be delayed as medical assistance was requested. Despite the best of care and diligence on your behalf as a driver, sometimes these things just happen.

Those travelling with children in prams and disabled passengers in wheelchairs have special needs, namely a “low-floor” or “flat-floor” bus. Step-buses, which are the older models with steps inside, are not suitable for carrying these for safety reasons. As a result, it can be quite disheartening for a passenger who has looked up the timetables and chosen to wait for a service advertised as “wheelchair friendly” to have a driver with a step-bus turn up. This often leads to some verbal exchange, although often it’s through no fault of the driver – it’s a result of dynamic dispatching. Once reported to dispatch, often they will find a way to accommodate the needs – this could include getting another route to make a special diversion or stop. Especially for disabled passengers towards the end of a driver’s shift, some drivers request special permission from dispatch to make a final special run for a disabled passenger left waiting for the next service – taking them home directly. It is a very nice gesture, one which seems to be granted in most occasions. That’s what I call service.

Occasionally, drivers do radio in to try and help lost passengers who want to go somewhere but don’t know how to get there. Other times, the drivers don’t know which stop is the optimum stop for a given destination and will request help from dispatch. While helpful drivers may do this, it’s not something that is expected of them especially when information is readily available online or through apps. But this isn’t a big issue compared with some passengers who may be suffering from dementia and don’t know where “home” is. Drivers have reported not being able to find ID with an address, not being able to extract a destination from the passenger and eventually having a passenger disembark the bus in a state of confusion and crossing the road to the bus stop opposite as if to catch the bus back. Drivers acting upon their duty of care genuinely radio in with concerns about these passengers, asking for drivers in both directions to keep a look-out and ask the passenger where they are trying to go. Other times, drivers are faced with a language barrier as foreigners who don’t speak any English attempt to get help from their driver. In the end, there’s only so much one can do.

One potentially big hassle is that of lost property. Someone leaving an item on the bus can mean that you are called-up over the radio to search for and secure the property, to schedule a rendezvous with the owner at an interchange (which they sometimes don’t show up or can’t be identified), or a rendezvous with another bus driver who is currently driving the owner around on another route, or a rendezvous with the depot to secure it. Under no circumstances are drivers permitted to take any lost property home (for good reason). If not, finding it afterward will still mean you have to secure and report the item, making for administrative hassle. Commonly lost items include wallets, phones and back-packs.

In the end, while some drivers might come off as rather unsympathetic and unhelpful at times, there are definitely quite a few drivers who are the complete opposite. I hear them on the radio everyday, going above and beyond to make sure everyone gets home safely.

“Back to the Depot” ≠ Going Home

After being on the road for nearly the maximum allowed number of hours and picking up a few overtime runs to help others out of trouble, finally:

Driver: 123 Zulu, just finished 456 Bravo at Fictional Interchange.”

Dispatch: “Copy that 123, thanks for your help tonight. Much appreciated. You can go back to depot.”

Driver: “Back to depot, copy. Have a goodnight.”

Unfortunately, that’s not the end of the day. It seems that drivers have a lot of paperwork to do once they get back, which includes various incident reports when something happens during a shift to the bus or to passengers in the bus, accident reports, shift surveys to note consistent late running issues, lost property submissions, bus defect reports and infrastructure reports where facilities might be lacking or signage missing, damaged or removed. From talking to various bus drivers, on a bad shift, this could easily take an hour if you’re unlucky. The worst part is that often the same deficiencies are reported the next time the shift comes around – making it seem like it was all in vain.

Conclusion

I hope that, through the course of this rather long article, you’ve learnt something about how your local bus operator might be operating and the stresses imposed on the drivers, dispatchers and maintenance staff involved. The bus company has all the incentive to ensure that the buses run on-time, providing a safe and comfortable journey for travellers. In some instances, we can see some parallels with aviation in the way some things are handled – the control, dispatch and tracking functions, along with the paperwork involved which is surprisingly “high tech” for something we rarely pay much attention to. Unfortunately, there are so many factors which can throw a spanner into the works and the best laid-out timetables are often thrown-out in favour of dynamically dispatching resources and committing overtime to ensure the quality of service is maintained.

Rather unfortunately, drivers are often at the receiving end of rather disrespectful behaviour and undeserved blame for problems outside their realm of control which only serve to make the job a rather stressful and one that might feel underappreciated. The drivers also have to deal with constant surprises, be it by the mechanical state of the bus, the result of passengers and their cargo, the state of the traffic, the desires of the dispatcher and other road users. As a result, it’s a big miracle that the bus even turns up on time half of the time.

Despite all of this, it’s clear that bus drivers have their own culture – you’ll see themselves giving each other a friendly wave, calling each other “bro” over the radio, or even having a friendly jab at each other on a first name basis. In the face of adversity, a camaraderie is born, as drivers understand each other’s hassles and are sympathetic to the conditions which they might end up finding themselves in, most of the time through no fault of their own.

It’s a rather unenviable job, but it’s an important one nonetheless – especially for people without other means of affordable transport, this is their mobility. So, if your bus turns up late or if the driver doesn’t acknowledge a polite “thank you”, don’t hold it against them. They’ve probably had a really hard day … which keeps on dragging on … and they’re just trying to do their best given the constraints.

Posted in Opinion, Radio | Tagged , , , , | 5 Comments

Site Update: HTTPS (at last), with a Terms of Use & Privacy Policy

Just the other day, an anonymous poster commented on one of my recent posts asking whether I had considered using HTTPS and reminding me that I needed a Privacy Policy due to the use of Google Adsense and Google Analytics. Thanks to this “nudge”, I’ve started the ball rolling in terms of rectifying these deficiencies.

The Road to HTTPS

While I have considered the use of HTTPS in the past and even got close to implementing it, there were a few problems which stopped me from doing so. The first reason was simply because everything worked just fine – why make a change that might risk breaking something? After all, most of the articles are reference in nature and users aren’t signing up for accounts and handing over gobs of personal information – it is a personal hobby site after all. The only real benefit of HTTPS would be to protect against “injections” man-in-the-middle style by evil ISPs.

The first real push came once Google started to down-rank HTTP websites over HTTPS counterparts. This gave me some impetus to upgrade, as I’d still want the site to remain visible for those who might need the information. At the time, I explored my options, which included buying a certificate from my hosting company but the cost was rather unreasonable for such a hobby site that’s being hosted as cheaply as possible. I did explore a no-cost option, namely that of Lets Encrypt, but the downside was the frequent certificate expiry which requires an automated renewal process to be run. This was something that didn’t look reliable or achievable from my shared hosting, so I had to abandon this.

Another push came when Google Chrome decided that it would begin marking HTTP websites as “not secure”. While ideologically, I don’t agree with this marking, it could needlessly scare away visitors who don’t understand exactly what it meant. I decided that I might need to go SSL sooner or later, so I tried to implement CloudFlare Flexible SSL.

While CloudFlare Flexible SSL isn’t as secure as a full SSL solution, it’s still a much easier option to deploy without having the cost of getting a dedicated HTTPS certificate or moving away from shared hosting. It still provides encryption and secures the link between the CloudFlare CDNs to the end user, which should provide man-in-the-middle protection, at the cost of a potential slow-down of the website and increased CPU usage due to the need to decrypt the data. The other downside is that the site may become unreachable from older browsers which don’t support the SNI feature of the certificate, but I suppose this is an acceptable compromise for the benefits which include being able to locally cache content and use of HTTP/2 and Brotli Compression to speed up content delivery. At the moment, they are willing to serve sites for free, but I’m not sure how long it might last.

Unfortunately, the first few times I tried it, the site misbehaved. The main reason involved links that were hard-coded to HTTP resources resulting in mixed-content errors. While I could redefine my site URL to HTTPS, as my web host is not actually offering HTTPS, this would make it impossible to access my site if I ever removed CloudFlare from the chain. I also didn’t want to author and upload through CloudFlare either, so short of taking down the site for extended times for migration, I turned the option back off and scratched my head.

With this final push, I decided to give it another shot today – this time, determined to set it up right. Without a back-up staging area, I had to make my modifications to the live site (so sorry if things went a bit funny this morning). Ultimately, I had to update a number of script elements and set up a number of rewrite rules to make things work the way I wanted. The result of this was the reward of HTTPS with a green padlock icon:

I spent quite a bit of time tweaking earlier today, so hopefully everything is operating correctly. Inevitably, some things could break as a result of this change, so do let me know if you spot something strange, but hopefully we’ll be running HTTPS from now on so everyone can be happy.

A Privacy Policy?

As a hobby site, I never thought about needing a privacy policy or terms of use document. I don’t allow users to sign up for an account and they leave comments voluntarily, so I thought I was fine. However, I didn’t realise that when I added Google Analytics and Google Adsense that this meant I actually needed one. I suppose things take time – it took me almost three years to just put a copyright symbol into the footer. I tend to focus more on content than administrative things – that’s why my site still looks like “2010”.

As a result, I’ve now put up a Terms of Use & Privacy Policy page which contains some information about what is collected and how one can protect themselves against this information collection. It required some research on my behalf to put together and might change in the future, but it’s at least a start.

But it did make me consider – while I do rely on ad revenue as a way to fund the web hosting, it might not be worth it given the cost to the privacy of the visitors. While I enjoy having some figures about viewership and devices, the fact that Google collects this information and might use it for broader tracking makes me think of whether it was worth continuing to run these services. As much as I had trusted Google in the past, it seems that they are increasingly showing their evil side. As a result, there is a distinct possibility that I may distance myself from their services in the future.

For those who are concerned, I completely understand and I have no objection to your use of tracking/advertising blocking third-party add-ons or via Google Opt-Out.

Other (Random) Stuff

I couldn’t help myself – I just had to know what runs the TP-Link TL-SG1008 8-port Gigabit Switch …

… it’s a Realtek RTL8370N. At least my guess was accurate. This chip is actually capable of managed operation, but the unit isn’t configured to do so. The small EEPROM contains two-byte values stored in little-endian mode with a length value (12-bit) followed by register address and value. Based on the two efforts I found to hack these switches, it seems that it isn’t exactly a trivial operation. To run a full managed firmware will require a large Flash chip and changes to the strapping resistors to set the 8051 to enabled and run the code on the chip. To modify the operation without that, either you can modify the register address and value pairs on the EEPROM or you can use the SMI bus to change the configuration. The difficulty is that there are a bucketload of registers and the documentation of values and their functions are only vaguely described due to a lack of full datasheet (as that is under NDA). Just attempting to understand what the existing EEPROM’s code does was a bit surprising, as some registers were being repeatedly overwritten and a number of addresses used are not documented at all.

In the meantime, I’ve been building myself a few cables after my connectors from element14 arrived. Those who use barrel jacks will be familiar with the annoyance the two 5.5mm outer-diameter types have, as their centre pin can be either 2.1mm or 2.5mm. Connected the wrong way, either they will fit but make poor intermittent contact, or not fit at all. As a result, I built myself some adapter leads – 2.1mm to 2.5mm and 2.5mm to 2.1mm. Problem solved.

Another issue is that I have oodles and oodles of power-boards but I can never seem to get enough space to fit all my wall warts. But a lot of equipment doesn’t actually use the adapter to even 20% of its current rating! This even applies to things like Ethernet switches and passive PoE based equipment. I can understand the motivation – lower loading means less heat and longer lifetimes, as well as keeping only one model of power adapter in stock keeps costs low. However, lightly loaded switchmode supplies are vastly less efficient. As a result, there’s a lot that can be done to save on wall wart madness – one way is to buy a cheap open-frame power supply (I have a 5V/8A unit for $20) and build yourself the wires necessary to hook it up to the devices. Another is just to build simple “multi-way” adapters for the DC-side to break one connection into three – top version for 2.5mm pins and bottom for 2.1mm pins. Unfortunately, in-line barrel jacks are not that easily available, so I had to go for PCB mounted sockets instead with copious amounts of heatshrink.

So far, this has let me run two switches, two VoIP ATAs and several USB-powered devices (including two Raspberry Pis and the Fingbox) from a single 5V/8A open frame supply. Lots of plugs saved (replacing seven with just one) – especially when considering that warts sometimes can’t sit next to one another.

Another thing I thought I’d mention – in the past week, the site has had a few periods of unavailability. Unfortunately, it seems that people online don’t have much better to do than to subject my poor site to 40 to 100 requests per second for one to two hours at a time causing resource exhaustion. Despite a certain level of protection, there will always be a few that “get through” and might need some manual intervention to encourage them to move on. Sadly, there’s not much I can do about this, as if I buy more resources, that’s only going to be soaked up by these attacks and sit idle otherwise …

Conclusion

I hope everything works and the site is now working in HTTPS for everyone. If you spot any issues – drop me a line. I’ve also managed to write-up a terms of use & privacy policy, which was well overdue, so I hope that’s useful.

In the interim, I managed to finally work out what powers the TL-SG1008 and get myself thoroughly confused about what the EEPROM data is actually configuring. Unfortunately, it didn’t seem fruitful to modify it owing to a lack of documentation even though the chip is definitely capable.

I also managed to reduce my wall wart adapter hell by building a number of barrel-jack splitters and reduce my headaches by building an adapter to go between 2.5mm and 2.1mm plugs.

Hopefully, I’ll have some time to put some more content up soon :).

Posted in Uncategorized | Tagged , , | 4 Comments