Thinktank

My position on China

The last few years have been a testing time for world politics. Recent events have seen much sabre-rattling, but really, none of this has suddenly “appeared”… it’s been slowly bubbling away for some time now.

Economic tunnel-vision

For a long time now, much of our world has revolved around the unit of currency. Call it the US dollar, the Australian dollar, the British Pound, Chinese Yuan, whatever… for the past 50 years or so, we have been “seduced” by two concepts which developed in the latter part of last century:

economies of scale
just-in-time production

The concepts are on the surface, fairly simple.

Just-in-time production forgoes having a large stock and inventory of components to feed your supply-lines in favour of ordering just enough of what you need to fulfil the orders you have active at the present moment. So long as nothing disrupts your supply lines, all is rosy. You might keep a small inventory just as a buffer, but in general, that might only last a day or so.

Economies of Scale was the other concept that really took hold last century, and was the reason why smaller workshops got shut down in favour of making lots of a widget in one central place, and shipping it out to everywhere from that one point.

Again, works great, until something happens in that place where you are doing the manufacturing, or something happens that hampers your ability to shift parts or product around.

The latter in particular took a dark turn when instead of making things close to where the demand was, “we” instead outsourced it, shifting the production to places where the labour was cheapest. As a consequence, many countries are forced to import as they no longer have the expertise or capabilities to manufacture products locally.

Both these concepts were ideas conceived with people wearing rose-coloured glasses, they emphasise cost-cutting over contingency plans on the grounds that disruption to manufacturing and supplies are unlikely events.

The rise of “the world’s factory”

Over time, companies pushed this concept of centralised manufacturing to extremes, whereby they were largely making things in one place. Apple for instance, were leaning heavily on Foxconn in China for the manufacture of their hardware.

None of this is without precedent, when I was growing up, Nike used to cop a lot of flack for the exploitation of workers in various third-world localities.

That said, history has often had something to say about putting all of one’s eggs in a single basket. There’s mostly nothing wrong with having products made in China, the problem is having things made exclusively in China.

At first, products made in China were seen as dodgy knock-offs of things made elsewhere. The same was said of things made in Japan in the 1950s and 1960s… but then Japan improved their systems and processes, and with it, the products they made improved too. In the case of China, initially things were done “cheaply”, which gave rise to a perception that things made in China were all “dodgy”.

Over time, processes again improved, and now there are some great examples of products and services, which are designed and built by people based in China. Stuff that works, and is reliable. There are some very smart people over there who are great at their craft.

That said, manufacturing all revolves around the dollar, and so when it came to cutting costs, something had to give.

Trouble in Xinjiang

With this global demand for manufacturing, China had a problem trying to find people to do the mundane jobs. Quality had to be maintained, and so some organisations over there tried to solve the cost problem a different way: cheaper labour.

Now, it’s well known that China’s government is not a government that particularly values individualism. This is evident in the manner in which the Tienanmen Square protests were so violently silenced.

The Uighur Muslim community is one such group that has been in their sights for a long time. This is a group that has been clamped-down on for more than 6 years. Over time, a narrative was developed that tried to cast this group as being “trouble makers” in need of “re-education”.

Over time, members of this community found themselves co-opted into being the cogs in this “global” factory. At first, such actions were hidden from view, including from the direct customers of these factories.

COVID-19 makes its entrance

So, over time, global manufacturing has shifted to China, in some cases involving forced labour in the effort to drive the cost down and make the end product seem more competitive.

Much of these problems have been hidden from the outside world, but for now, whilst we’re starting to learn of these issues, we still do the majority of our manufacturing in one country.

Then, about this time last year, a bizarre respiratory condition started showing up in Wuhan. Nobody knew much about this condition, other than the fact that it was discovered it was highly contagious.

Even today, we’re still unsure exactly how it came about, but the smart money is that it jumped from some reservoir host such as a bat, via some intermediate host, to humans. Bats in particular are major carriers of all kinds of corona-viruses, and as such, are a highly probably suspect in this.

I do not believe it is synthetic in origin.

COVID-19 threw a major spanner in the works for everybody. Community event calendars looked like an utter train-wreck with cancellations and deferrals all over the place. For me, some of the casualties I was looking forward to include the 2020 Yarraman to Wulkuraka bike ride and numerous endurance horse-riding events (where I assist in operations).

It also threw a major spanner in the works for just-in-time manufacturing (since freight was running inefficiently due to a lack of flights) and rolling shut-downs across China as COVID-19 did its worst.

Some businesses have already closed for good.

Knee-jerk reactions

Numerous countries, notably ours, called for an investigation into the origins and initial handling of the COVID-19 pandemic.

I for one, think such an investigation should go ahead. We owe it to the people who have lost their lives, and those who have lost their livelihoods, to this condition, that we try and find out what went wrong. It’s not about blaming people.

We’re not interested in who made the mistakes, it’s more a question of what the mistakes were. This event will repeat itself again, and again, until such time as we get to understand what “we” (globally) did wrong.

China’s government does not seem to have seen it this way. It’s as if they see it as a witch-hunt. As a result, we as a nation that seems to have been singled-out, with heavy tariffs placed on goods that we as a nation export to China.

Notably absent in this trade-war is iron ore, partially because the other major producer of iron ore, Brazil, has been left a complete basket-case by this pandemic, and Australia was a major supplier of iron ore long before COVID-19 reared its ugly head.

A plan “B”

Right now, things are escalating in this diplomatic row. Whilst the politicians are trying to resolve this with as little fuss as possible, I think China’s position is becoming very clear. They’ve told the world “F You” in no uncertain terms.

We are most definitely dealing with a rebellious and violent teenager, more than capable of smashing holes in a few walls and inflicting grievous bodily harm.

I think it would be wonderful if things could be reset back to the way they were, but at the same time, I think that really, we may need to realise that “peak China” days may be behind us now.

I know there are organisations that have built their entire business model around exports to China, and that literally overnight, conditions have changed which now make that greatly risk business viability.

They are geared around the huge appetite that this country’s people have previously demonstrated for our goods and services. I think now, more than ever, we should be looking around. Where else can I outsource to? Where else can I sell to? How can we make do with less demand?

If China does come around, then sure, maybe a certain portion of your market can be serviced there. I think it folly though to be reliant on one single region for your supply or demand though.

Two or three alternatives may not totally balance things, but having at least a partial income is better than none at all!

The Australian coat-of-arms features the emu and the kangaroo. These animals are quite different from one another, but they share a few common attributes. Yes, some might say they’re two of the less brainy members of the animal kingdom, but also, they are not known for going “backwards”.

Whilst we momentarily look over our shoulder at our past, I think it important that we keep moving “forwards”.

Learning from our mistakes

I think in all of this, it’s fair to say none of us are perfect. Yes, our SAS troops have been implicated in some truly horrendous war crimes. Not all of them, thankfully, but enough to cast a cloud over the military in general. Some of the Army’s chopper pilots are not exactly famous for fast reporting of fires either.

We’re investigating this, and yes, some of the top brass are ducking for cover, as it’s likely some know more than they’ve been letting on. An analysis of what went wrong will be done, and we, collectively, will learn from those mistakes.

In the case of COVID-19, for the first few months of 2020, we were told “No, we don’t need help, we’re fine, we’ve got this!”. Taiwan saw this, and immediately sprang to action, as did many other nations close to China. They’ve seen similar things happen before (SARS, MERS), and so maybe their scepticism shielded them somewhat.

I think one of the biggest lessons of all is to realise that asking for help is not a sign of weakness, it’s a sign of maturity. We’re on this planet, together. We are in this mess, together. We need to work this all out, together.

What am I doing?

So, based on the above… where do I sit? Not on the fence.

I myself have started seriously considering my suppliers.

In particular, I have practically destroyed my credentials for AliExpress, having bought the last few things I’m likely to want from there. I’ve ordered printed circuit boards from a supplier in Hong Kong.

During last year, I had ordered a few PCBs from their sister factory in mainland China as I was concerned about the civil unrest there (and on that, I do think the people there have a valid point to raise) causing delays, but had originally intended to move things back once things settled down. However, with China being so adamant that Hong Kong is “theirs”, I’m forced to treat Hong Kong the same as mainland China.

As such, I’ll probably be looking to the US, Europe or India to evaluate options there. I might still use the old Hong Kong supplier, but they won’t be the sole supplier.

Where possible, I’ll probably be paying more attention to country-of-origin for products I buy from now on, and preferring local options where possible. This won’t always be the case, and some things will have to be imported from China, but I aim to diversify my sources.

I may start making things myself. Yes, time-consuming, expensive, but ultimately, this means I become the master of my own destiny, it’s likely a worthwhile journey to undertake.

Above all, I am not out to discriminate against the people of China. I may not always agree with some of their customs, but that does not give one the right to indulge in racism. My only real complaint with China at this time, is the conduct of its government.

Maybe with time, diplomatic relations might turn this around, and we may see a more co-operative Chinese government, only time will tell on that.

In the meantime, I plan to not reward their government for what I consider, bad behaviour.

Re-building a Logitech Headset – Part II

So, today I was doing some work for my workplace, when a critical 4G modem-router dropped offline, cutting me off. Figuring it was a temporary issue, I thought I’d resume this headset rebuild.

The replacement battery had turned up a few weeks back, a beefy 1000mAh 3.7V LiPo pack intended for Raspberry Pi PiJuice battery supplies. This pack was chosen because it has a similar arrangement to the original Logitech battery: single cell with a 10k thermistor. As a bonus, the pack appears to be at least triple the original cell’s capacity. I just had to wire it up.

The new battery being charged by the headset circuitry

The connectors are not compatible, being both physically different sizes and the thermistor and 0V pins being swapped. Black and Red are the same conventions on both packs, that is, red for +3.7V and black for 0V… the thermister connects to the blue wire on the old pack and yellow on the new pack.

I’m at two minds whether to embed the electronics directly into the earmuffs, or whether to just wire the microphone/speaker connections to a DIN-5 connector to make it compatible with my other headsets.

For now at least, the battery is charging, not getting hot, and the circuitry detects the base transceiver when it is plugged into a laptop USB port, so the circuitry is still “functional”.

2020/11/04 by Redhatter (VK4MSL) Computing Public Syndication Thinktank 0

Trolling Telephone scammers with Music On Hold

So, this is not really news… for the past 12 months or so, the scammers have been busy. They’ve been calling us long before we moved to the NBN, and of course we’ve just hung up the moment they started their spiel. The dead giveaway is the seconds of silence at the start of the call. Dead silence.

Of course, it’s not just the NBN, we’ve had “Amazon Prime”, “Visa”, “Telstra” and others call. Far and above all others has been NBN-related scams.

The latest on the NBN front is they claim your connection has been “compromised” by “other users”, in a British accent.

This is the call I received this morning. You can hear other callers in the back-ground. This is not a professional call-centre, this is a back-yard operation!

The home number recently moved from the PSTN to a VoIP service, so this actually gives me a lot of scope for dealing with this. For now, it’s a manual process: when they call, put them on hold. If I put someone on hold on this number, you better be a Deborah Harry fan!

Long term, I’ll probably look at seeing if I can sample the first 2 seconds of call audio, and if silent, direct the call to a voicemail service or IVR menu. In the meantime, it’s a manual process.

Thankfully we get caller ID now, something Telstra used to charge for.

MoH considerations

There’s three big considerations with music on hold:

Licensing: You need to do the research into how music is licensed in your country. If you want to be safe, go look for something that is “public domain” or one of the “Creative Commons” family of licenses. In Australia, you probably want to have a look at this page if you want to use a piece of commercial music (like “Hangin’ On The Telephone”).
Appropriateness: is the caller likely to get offended by your choice of hold music? (Then again, maybe that’s your goal?)
Suitability for your chosen audio CODEC: Some audio CODECs, particularly the lower-bitrate ones, do an unsurprisingly terrible job, with music.

Regarding point (3) always test your music choice! Try different CODEC settings, and ensure it sounds “good” with ALL of them. Asterisk actually supports transcoding, but will choose the format that takes the least effort. RIFF Wave files (.wav) can be used too, but they must be mono files.

I slapped a CD-quality 44.1kHz stereo version in there, and wondered why it got ignored: that’s why — it wasn’t mono and Asterisk won’t down-mix.

Signed 16-bit linear is a pretty safe bet: effort of going to that to PCMA/PCMU (G.711a/G.711u) isn’t a big deal, but to anything else, you’re at the mercy of the CODEC implementation. Using G.722, things sounded fine, but I found even with Speex settings cranked right up (quality=10 complexity=10 enhancement=true), my selection of audio sounded terrible in Ultra-wideband Speex mode. I wound up with the following in my MoH directory:

vk4msl-gap# ls -l /usr/local/share/moh/
total 8280
-rw-r--r--  1 root  wheel   527836 Aug 29 17:02 moh.sln
-rw-r--r--  1 root  wheel  1055670 Aug 29 17:02 moh.sln16
-rw-r--r--  1 root  wheel  2111342 Aug 29 17:01 moh.sln32
-rw-r--r--  1 root  wheel   104793 Sep  5 12:17 moh.spx
-rw-r--r--  1 root  wheel   177879 Sep  5 12:34 moh.spx16
-rw-r--r--  1 root  wheel   184617 Sep  5 12:16 moh.spx32

.sln* is for 16-bit signed linear, the 16 and 32 suffixes refer to the sample rate, so 16kHz (wideband) and 32kHz (ultra-wideband). These should otherwise be “raw” files (no headers). Use sox <input> -r <rate> -b 16 -e signed-integer -c 1 <output>.sln to convert.
.spx* is Speex: Here again, I’ve got 8kHz, 16kHz and 32kHz versions. These were encoded using the following command: speexenc --quality 10 --comp 10 moh.wav moh.spx

There are various other CODEC selections, but right now, I’ve just focussed on signed linear and Speex since the latter is what needs careful attention paid. I tested between my laptop running Twinkle and the ATA on my network, and when I placed the call on hold from my laptop it sounded fine there, so I figure it’ll be “good enough”.

“Visa Security Department”

So, had “Visa” call me this morning… this too, is another scam. Anonymous caller. Bear in mind I do not actually have a credit card. Never have had one, never will.

“Visa security department”

They didn’t stick around, seems their system just drops the call if it hears a noise which isn’t a DTMF tone.

Interestingly, both this call, and the previous one were G.711u (µ-law PCM). Australia normally uses A-law PCM. America uses µ-law encoding. What’s the difference? Both are logarithmic encoding schemes. µ-law encoding has a wider dynamic range, however A-law has less distortion for quieter signals.

“Amazon”

Almost the same structure as before. Audio CODEC was G.729 this time.

2020/09/05 by Redhatter (VK4MSL) Humour Public Service Announcements Public Syndication Rants Thinktank 0

Re-building a Logitech Headset

So, lately I’ve been working from home, which means amongst other things, playing music as loud as I like, not getting distracted by co-workers, and the kettle a short walking distance from my workspace.

Eventually though, I will have to return to the office. For this aim, I’ll need to be able to “drown out” the background noise. Music is good for this, but not everyone is into the same tastes as I am — I am a bit of a music luddite.

Years ago (when the ink was drying on my foundation license) I purchased a Logitech Wireless headset. Model A-00006 (yes, that is quite old now). This headset worked, but it did have two flaws:

the audio isolation wasn’t great, so they tended to “leak” sound
they had the dreaded asymmetric audio sample rate problem with JACK.

Now, for home use I bought a much nicer set which solves issue (2) and isn’t too bad with (1), but I’d like to keep them home. (2) isn’t a problem at work since I don’t generally have the need for the audio routing I use at home. So (2) isn’t going to be a problem.

This headset sat in a box for some years, and over time, the headband and earpads have fallen to bits. The electronics are still good. What if I bought a pair of earmuffs and stuffed the old headset guts inside those? That’d solve issue (1) nicely.

Getting inside

These things didn’t open up without a fight. I found that where the speakers are concerned, you will permanently break the housing. The two sides are joined by a 8-wire ribbon cable. The majority of the electronics is in the right-hand side. The battery is most of the guts of the left side.

You’ll need to destroy the headband to liberate the ribbon cable, and you’ll need to destroy the speakers’ housing to get at the screws behind.

I now have the un-housed headset guts sitting on the table, with the original charger plugged in charging the very flat battery, which is a single-cell 3.7V LiPo pouch cell; no idea what capacity it is, I doubt it’s more than 200mAh.

Charging

I plugged everything back together and tried the headset out. It still works, although instead of indicating a solid amber LED for charging, it was showing a slow blink.

fccid.io has a copy of the original documentation online, as well as photos of the guts here. In that, it did not discuss what a “slow blink” meant, which had me concerned that maybe the battery had been left too long and was no longer safe to charge.

Battery voltage whilst charging is sitting around 4.2V, which sounds fair for a 3.7V cell. It eventually stops blinking, going solid, but then the other LED turns RED. Disconnecting the battery reveals 0V across the pins.

So I might be up for a new battery, the PiJuice batteries look to be a similar arrangement (single cell with termistor pin) and may be a good upgrade anyway.

Next steps

I prefer the microphone on the right-hand side, so that’s one thing I’ll be looking at changing. The ribbon cable connects using small FPC connectors, so I’m thinking I might see if I can de-solder those and put a beefier 2.54″ KK-style connector in its place. This will require soldering some wire-wrap wire up to the pins, but the advantage is it’s a much easier connector to work with.

The break-out board on the left side is very simple, no components other than a momentary switch for detecting the microphone boom position, and pads to which the left speaker, microphone, mute LED and battery connect. I’ll still put the battery in the left side, so there’ll still be 5 wires running across the headband. It should be easier to interface with a new battery as well doing this.

I will also have to bring the buttons and switch out to the outside of the earcup, so I’ll probably use KK connectors for those too. The power switch is a through-hole part, so that should be easy.

I’ll probably replace the proprietary power connector with a barrel jack too. Not sure if these will charge from 5V, the original charger has a 6V output.

I think once I’ve got more hacker-friendly connectors onto this, I should be able to look at readying the new home for the electronics.

2020/08/08 by Redhatter (VK4MSL) Computing Public Syndication Thinktank 0

HTML Email ought to be considered harmful

Some people make fun of my plain-text emails, but really, I think it’s time we re-consider our desire for colours, hyperlinks and inline images in email messages, especially for those who use web-based email clients as their primary email interface.

The problem basically boils down to this: HTML gives too much opportunity for mischief by a malicious party. In most cases, HTML isn’t even necessary to convey the information required. Tables are about the only real “feature” that is hard to replicate in plain text, for everything else there’s reasonable de-facto standards already in existence.

Misleading hyperlinks

HTML has a feature where a link to a remote page can take on any descriptive text the author desires, including images and other valid URIs. For example, the following piece of HTML code is perfectly valid:

<a href="http://www.google.com.malicious.website.example.com/">
   http://www.google.com
</a>

There are many cases where this feature is “useful”, however in an email, it can be used to disguise phishing attempts. In the above example, the link is claiming to be to Google’s search website, however would otherwise re-direct that user to some other, likely malicious, website.

Granted, not every user can read a URI to determine if it is safe. There are adults who “grew up with the Internet”, that have never typed a URI in an address bar ever, instead relying on tools like search engines to locate websites of interest.

However, it would seem disingenuous to say that because a proportion of the community cannot read a URI, we should hide any and all links from everybody. For that small portion, showing the links won’t make a difference, but it will at least make it easier to avoid such traps.

Media exploits

Media decoders are written by humans, and humans are imperfect, thus it is fair to say there are media decoders that contain bugs, some of which could be disastrous for computer security.

Microsoft had such a problem in their GDI+ JPEG decoder back in 2004. More recently, there was a kernel-level security vulnerability in their TrueType font parser.

Modern HTML allows embedding of all this, and more. Most email clients will also allow you to “preview” an email without opening it. If an email embeds inline media which exploits vulnerabilities such as the one above, just previewing it will be sufficient to gain access.

Details are scarce, but it would appear it was a vulnerability along these lines that allowed unauthorised access into the Australian National University back in 2018.

Scripting

Modern web standards allow all kinds of means for embedding scripts, that is, small pieces of interpreted code which runs client-side in the HTML renderer. ECMAScript (JavaScript) can be embedded:

in <script> tags (the traditional way)
inside a hyperlink using a javascript: URI
HTC and XBL features in Internet Explorer and Mozilla Firefox, respectively.

Probably lots more ways I haven’t thought about.

Web-based email clients

Now, a stand-alone email client such as Microsoft Outlook, Eudora or Mozilla Thunderbird can simply not implement the scripting features, however the problem is highly acute where web-based email clients are used.

Here, you’re viewing an email in a HTML engine that has complete media and scripting capabilities. There’s dozens of ways to embed both forms of content into a blob of HTML, and you are entirely at the mercy of your web-based email client’s ability to sanitise the HTML before it dumps it inside the DOM tree that represents your email client.

As far as the web browser is concerned, the “email” is just another web page, and will not hesitate to execute embedded scripts or render inline media, whether the user wishes it to or not.

It’s not known what ANU uses for their email infrastructure, but many universities are big fans of web-based email since it means they don’t have to explain to end users how to configure their email clients, and provides portability for their users.

Putting users at risk

Despite the above, it would appear there are lots of organisations that are completely oblivious to this problem, and insist on forcing people to render their emails as HTML, putting their customers/users at risk of security breach.

The purpose of multiple formats in the same email is to provide alternate formats of the same content. Not to provide totally different emails because you can’t be stuffed!

For example, my workplace’s hosting provider, recently sent us an email, which when viewed as plain text, read as follows:

Hello Client,
 
Unfortunately your email client is outdated and does not support HTML emails, our system uses HTML emails as standard. You will NOT be able to read this email.
 
HOW DO I READ THIS EMAIL?
 
To read this email please login to your domain manager https://hostingprovider.example.com/login/ and click on Notifications to see a list of all sent emails.
 
Thank You
 
Customer Support

The suggestion that an email client configured to read emails as plain text, counts as it being “outdated” is naïve in the extreme, and I’d expect a hosting provider to know better. I’m thankful I personally don’t purchase services from them!

Then there’s financial service providers. One share registry’s handling of the situation is downright abusive:

Link Market Services sent numerous emails that looked exactly like this.

Yeah, rather than just omitting the text/plain component and letting the email client at this end try to render the HTML as plain text (which works reasonably well in many cases), in this case, they just sent an empty text/plain body:

From: …redacted… <comms@linkmarketservices.com.au>
To: …redacted…
Reply-To: donotreply@linkmarketservices.com.au
Date: Wed, 29 Jul 2020 04:42:30 +0000
Subject: …redacted… Funds Attribution Managed Investment Trust Member Annual
 Statement
Content-Type: multipart/alternative;
 boundary=--boundary_55327_8fbc43bd-48f3-4aa1-9ab7-9046df02b853
ZMID: 9f485235-9848-49cf-9a66-62c215ea86ba-1
Message-ID: <0100017398e10334-d45a0a83-ff4d-4b83-8d19-146b100017f6-000000@us-east-1.amazonses.com>
X-SES-Outgoing: 2020.07.29-54.240.9.110
Feedback-ID: 1.us-east-1.oB/l4dCmGdzC38jjMLirCbscajeK9vK6xBjWQPPJrkA=:AmazonSES


----boundary_55327_8fbc43bd-48f3-4aa1-9ab7-9046df02b853
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"


----boundary_55327_8fbc43bd-48f3-4aa1-9ab7-9046df02b853
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"

PCFET0NUWVBFIGh0bWw+Cgo8aHRtbCBsYW5nPSJlbiI+CjxoZWFkPgo8bWV0YSBjaGFyc2V0PSJ1
dGYtOCI+CjxtZXRhIGNvbnRlbnQ9IndpZHRoPWRldmljZS13aWR0aCwgaW5pdGlhbC1zY2FsZT0x
IiBuYW1lPSJ2aWV3cG9ydCI+CjxtZXRhIGNvbnRlbnQ9IklFPWVkZ2UiIGh0dHAtZXF1aXY9Ilgt

Ohh yeah, I’m so fluent in BASE64! I’ve since told them to send it via snail mail. Ensuring they don’t burn down forests posting blank sheets of A4 paper will be their problem.

The alternative: wiki-style mark-up

So, our biggest problem is that HTML does “too much”, so much that it becomes a liability from a security perspective. HTML wasn’t the first attempt at rich text in email… some older email clients used enriched text.

Before enriched text and HTML, we made do with various formatting marks, for instance, *bold text might be surrounded by asterisks*, and /italics indicated with forwardslashes/. _Underlining_ could be done too.

No there was no colour or font size options, but then again this was from a time when teletype terminals were not uncommon. The terminals of that time only understood one fixed-size font, and most did not do colour.

More recently, Wikis have built on this to allow for some basic mark-up features, whilst still allowing the plain text to be human readable. Modern takes of this include reStructured Text and Markdown, the latter being the native format for Wikis on Github.

Both these formats allow for embedding images inline and for tables (Markdown itself doesn’t do tables, but extensions of it do).

In email clients such images should be replaced with place-holders until the user clicks a button to reveal the images (which they should only click if they trust the sender).

Likewise, hyperlinks should be rendered in full, e.g. in a web-based client, the link [a cool website](http://example.com/) might be rendered as <a href="http://example.com">[a cool website](<code>http://www.example.com</code>)</a> — thus allowing for malicious links to be more easily detected. (It also makes them printable.) Only plain text should be permitted as a “label” for a hyperlink.

Use of such a mark-up format would have a number of benefits:

the format is minimal, meaning a much reduced attack surface for security vulnerabilities
whilst minimal, it would cover the vast majority of peoples’ use cases for HTML email
the mark-up is light-weight, reducing bandwidth for those on low-speed links or using lower-power devices

The downside might be for businesses, which rely on more advanced features in HTML to basically make an email look like their letter head. The business community might wish to consider the differences between a printed letter sent via the post, and an email sent electronically. They are different beasts, and trying to treat one as a substitute for the other will end in tears.

In any case, a simple letter head could be embedded as an inline image quite safely if such a feature was indeed required.

It is in our interests to curtail the features used in email communications if we intend to ensure communications remain safe and reliable.

2020/08/05 by Redhatter (VK4MSL) Public Syndication Rants Thinktank 0

Culinary Experiment: Coffee flavoured pikelets

I noted at the last horse endurance ride we did up at Imbil that we had a packet of pancake mix whose “best-before” date had expired early last year. We were too busy that event to go making pancakes for breakfast, so the packet wound up coming back with us in the van.

I made a note of this, bought a new packet to replace the one in the van (turns out there’s a second one there too!) and bring the old packet to use up. Thinking about this, I thought, why not experiment? What would it be like if I used coffee instead of water to make up the mix?

So, I poured in some coffee from the percolator up to the marking on the packaging, and whilst chatting on the Bayside District Amateur Radio Society morning “coffee net”, I cooked up a number of small pikelets.

No I won’t win awards for my pancake flipping skills… but they taste alright.

Two things I’d do different:

use slightly stronger coffee (the mix I used is perhaps a little weak, so the coffee flavouring is only subtle even though the colour is notably darker)
thicken the mixture up a bit so the pikelets are not as thin

In fact, not using >18 month old mixture, or doing the batter from scratch might help too!

2020/07/22 by Redhatter (VK4MSL) Public Syndication Thinktank 0

Phone patching to Zoom

Brisbane Area WICEN Group (Inc) lately has been caught up in this whole COVID-19 situation, unable to meet face-to-face for business meetings. Like a lot of groups, we’ve had to turn to doing things online.

Initially, Cisco WebEx was trialled, however this had significant compatibility issues, most notably, under Linux — it just straight plain didn’t work. Zoom however, has proven fairly simple to operate and seems to work, so we’ve been using that for a number of “social” meetings and at least one business meeting so far.

A challenge we have though, is that one of our members does not have a computer or smart-phone. Mobile telephony is unreliable in his area (Kelvin Grove), and so yee olde PSTN is the most reliable service. For him to attend meetings, we need some way of patching that PSTN line into the meeting.

The first step is to get something you can patch to. In my case, it was a soft-phone and a SIP VoIP service. I used Twinkle to provide that link. You could also use others like baresip, Linphone or anything else of your choosing. This connects to your sound card at one end, and a Voice Service Provider; in my case it’s my Asterisk server through Internode NodePhone.

The problem is though, while you can certainly make a call outbound whilst in a conference, the person on the phone won’t be able to hear the conference, nor will the conference attendees be able to hear the person on the phone.

Enter JACK

JACK is a audio routing framework for Unix-like operating systems that allows for audio to be routed between applications. It is geared towards multimedia production and professional audio, but since there’s a plug-in in the ALSA framework, it is very handy for linking audio between applications that would otherwise be incompatible.

For this to work, one application has to work either directly with JACK, or via the ALSA plug-in. Many support, and will use, an alternate framework called PulseAudio. Conference applications like Zoom and Jitsi almost universally rely on this as their sound card interface on Linux.

PulseAudio unfortunately is not able to route audio with the same flexibility, but it can route audio to JACK. In particular, JACKv2 and its jackdbus is the path of least resistance. Once JACK starts, PulseAudio detects its presence, and loads a module that connects PulseAudio as a client of JACK.

A limitation with this is PulseAudio will pre-mix all audio streams it receives from its clients into one single monolithic (stereo) feed before presenting that to JACK. I haven’t figured out a work-around for this, but thankfully for this use case, it doesn’t matter. For our purposes, we have just one PulseAudio application: Zoom (or Jitsi), and so long as we keep it that way, things will work.

Software tools

jack2: The audio routing daemon.
qjackctl: This is a front-end for controlling JACK. It is optional, but if you’re not familiar with JACK, it’s the path of least resistance. It allows you to configure, start and stop JACK, and to control patch-bay configuration.
SIP Client, in my case, Twinkle.
ALSA JACK Plug-in, part of alsa-plugins.
PulseAudio JACK plug-in, part of PulseAudio.

Setting up the JACK ALSA plug-in

To expose JACK to ALSA applications, you’ll need to configure your ${HOME}/.asoundrc file. Now, if your SIP client happens to support JACK natively, you can skip this step, just set it up to talk to JACK and you’re set.

Otherwise, have a look at guides such as this one from the ArchLinux team.

I have the following in my .asoundrc:

pcm.!default {
        type plug
        slave { pcm "jack" }
}

pcm.jack {
        type jack
        playback_ports {
                0 system:playback_1
                1 system:playback_2
        }
        capture_ports {
                0 system:capture_1
                1 system:capture_1
        }
}

The first part sets my default ALSA device to jack, then the second block defines what jack is. You could possibly skip the first block, in which case your SIP client will need to be told to use jack (or maybe plug:jack) as the ALSA audio device for input/output.

Configuring `qjackctl`

At this point, to test this we need a JACK audio server running, so start qjackctl. You’ll see a window like this:

This shows it actually running, most likely for you this will not be the case. Over on the right you’ll see Setup… — click that, and you’ll get something like this:

The first tab is the parameters screen. Here, you’ll want to direct this at your audio device that your speakers/microphone are connected to.

The sample rate may be limited by your audio device. In my experience, JACK hates devices that can’t do the same sample rate for input and output.

My audio device is a Logitech G930 wireless USB headset, and it definitely has this limitation: it can play audio right up to 48kHz, but will only do a meagre 16kHz on capture. JACK thus limits me to both directions running 16kHz. If your device can do 48kHz, that’d be better if you intend to use it for tasks other than audio conferencing. (If your device is also wireless, I’d be interested in knowing where you got it!)

JACK literature seems to recommend 3 periods/buffer for USB devices. The rest is a matter of experiment. 1024 samples/period seems to work fine on my hardware most of the time. Your mileage may vary. Good setups may get away with less, which will decrease latency (mine is 192ms… good enough for me).

The other tab has more settings:

The things I’ve changed here are:

Force 16-bit: since my audio device cannot do anything but 16-bit linear PCM, I force 16-bit mode (rather than the default of 32-bit mode)
Channels I/O: output is stereo but input is mono, so I set 1 channel in, two channels out.

Once all is set, Apply then OK.

Now, on qjackctl itself, click the “Start” button. It should report that it has started. You don’t need to click any play buttons to make it work from here. You may have noticed that PulseAudio has detected the JACK server and will now connect to it. If click “Graph”, you’ll see something like this:

This is the thing you’ll use in qjackctl the most. Here, you can see the “system” boxes represent your audio device, and “PulseAudio JACK Sink”/”PulseAudio JACK Source” represent everything that’s connected to PulseAudio.

You should be able to play sound in PulseAudio, and direct applications there to use the JACK virtual sound card. pavucontrol (normally shipped with PulseAudio) may be handy for moving things onto the JACK virtual device.

Configuring your telephony client

I’ll use Twinkle as the example here. In the preferences, look for a section called Audio. You should see this:

Here, I’ve set my ringing device to pulse to have that ring PulseAudio. This allows me to direct the audio to my laptop’s on-board sound card so I can hear the phone ring without the headset on.

Since jack was made my default device, I can leave the others as “Default Device”. Otherwise, you’d specify jack or plug:jack as the audio device. This should be set on both Speaker and Microphone settings.

Click OK once you’re done.

Configuring Zoom

I’ll use Zoom here, but the process is similar for Jitsi. In the settings, look for the Audio section.

Set both Speaker and Microphone to JACK (sink and source respectively). Use the “Test Speaker” function to ensure it’s all working.

The patch up

Now, it doesn’t matter whether you call first, then join the meeting, or vice versa. You can even have the PSTN caller call you. The thing is, you want to establish a link to both your PSTN caller and your conference.

The assumption is that you now have a session active in both programs, you’re hearing both the PSTN caller and the conference in your headset, when you speak, both groups hear you. To let them hear each other, do this:

Go to qjackctl‘s patch bay. You’ll see PulseAudio is there, but you’ll also see the instance of the ALSA plug-in connected to JACK. That’s your telephony client. Both will be connected to the system boxes. You need to draw new links between those two new boxes, and the PulseAudio boxes like this:

Here, Zoom is represented by the PulseAudio boxes (since it is using PulseAudio to talk to JACK), and Twinkle is represented by the boxes named alsa-jack… (tip: the number is the PID of the ALSA application if you’re not sure).

Once you draw the connections, the parties should be able to hear each-other. You’ll need to monitor this dialogue from time to time: if either of PulseAudio or the phone client disconnect from JACK momentarily, the connections will need to be re-made. Twinkle will do this if you do a three-way conference, then one person hangs up.

Anyway, that’s the basics covered. There’s more that can be done, for example, recording the audio, or piping audio from something else (e.g. a media player) is just a case of directing it either at JACK directly or via the ALSA plug-in, and drawing connections where you need them.

2020/06/01 by Redhatter (VK4MSL) Amateur Radio Computing Emergency Communications Public Syndication Thinktank WICEN 0

Pondering audio streaming over LANs

Lately, I’ve been socially distancing a home and so there’s been a few projects that have been considered that otherwise wouldn’t ordinarily get a look in on a count of lack-of-time.

One of these has been setting up a Raspberry Pi with DRAWS board for use on the bicycle as a radio interface. The DRAWS interface is basically a sound card, RTC, GPS and UART interface for radio interfacing applications. It is built around the TI TMS320AIC3204.

Right now, I’m still waiting for the case to put it in, even though the PCB itself arrived months ago. Consequently it has not seen action on the bike yet. It has gotten some use though at home, primarily as an OpenThread border router for 3 WideSky hubs.

My original idea was to interface it to Mumble, a VoIP server for in-game chat. The idea being that, on events like the Yarraman to Wulkuraka bike ride, I’d fire up the phone, connect it to an AP run by the Raspberry Pi on the bike, and plug my headset into the phone:144/430MHz→2.4GHz cross-band.

That’s still on the cards, but another use case came up: digital. It’d be real nice to interface this over WiFi to a stronger machine for digital modes. Sound card over network sharing. For this, Mumble would not do, I need a lossless audio transport.

Audio streaming options

For audio streaming, I know of 3 options:

PulseAudio network streaming
netjack
trx

PulseAudio I’ve found can be hit-and-miss on the Raspberry Pi, and IMO, is asking for trouble with digital modes. PulseAudio works fine for audio (speech, music, etc). It will make assumptions though about the nature of that audio. The problem is we’re not dealing with “audio” as such, we’re dealing with modem tones. Human ears cannot detect phase easily, data modems can and regularly do. So PA is likely to do things like re-sample the audio to synchronise the two stations, possibly use lossy codecs like OPUS or CELT, and make other changes which will mess with the signal in unpredictable ways.

netjack is another possibility, but like PulseAudio, is geared towards low-latency audio streaming. From what I’ve read, later versions use OPUS, which is a no-no for digital modes. Within a workstation, JACK sounds like a close fit, because although it is geared to audio, its use in professional audio means it’s less likely to make decisions that would incur loss, but it is a finicky beast to get working at times, so it’s a question mark there.

trx was a third option. It uses RTP to stream audio over a network, and just aims to do just that one thing. Digging into the code, present versions use OPUS, older versions use CELT. The use of RTP seemed promising though, it actually uses oRTP from the Linphone project, and last weekend I had a fiddle to see if I could swap out OPUS for linear PCM. oRTP is not that well documented, and I came away frustrated, wondering why the receiver was ignoring the messages being sent by the sender.

It’s worth noting that trx probably isn’t a good example of a streaming application using oRTP. It advertises the stream as G711u, but then sends OPUS data. What it should be doing is sending it as a dynamic content type (e.g. 96), and if this were a SIP session, there’d be a RTPMAP sent via Session Description Protocol to say content type 96 was OPUS.

I looked around for other RTP libraries to see if there was something “simpler” or better documented. I drew a blank. I then had a look at the RTP/RTCP specs themselves published by the IETF. I came to the conclusion that RTP was trying to solve a much more complicated use case than mine. My audio stream won’t traverse anything more sophisticated than a WiFi AP or an Ethernet switch. There’s potential for packet loss due to interference or weak signal propagation between WiFi nodes, but latency is likely to remain pretty consistent and out-of-order handling should be almost a non-issue.

Another gripe I had with RTP is its almost non-consideration of linear PCM. PCMA and PCMU exist, 16-bit linear PCM at 44.1kHz sampling exists (woohoo, CD quality), but how about 48kHz? Nope. You have to use SDP for that.

Custom protocol ideas

With this in mind, my own custom protocol looks like the simplest path forward. Some simple systems that used by GQRX just encapsulate raw audio in UDP messages, fire them at some destination and hope for the best. Some people use TCP, with reasonable results.

My concern with TCP is that if packets get dropped, it’ll try re-sending them, increasing latency and never quite catching up. Using UDP side-steps this, if a packet is lost, it is forgotten about, so things will break up, then recover. Probably a better strategy for what I’m after.

I also want some flexibility in audio streams, it’d be nice to be able to switch sample rates, bit depths, channels, etc. RTP gets close with its L16/44100/2 format (the Philips Red-book standard audio format). In some cases, 16kHz would be fine, or even 8kHz 16-bit linear PCM. 44.1k works, but is wasteful. So a header is needed on packets to at least describe what format is being sent. Since we’re adding a header, we might as well set aside a few bytes for a timestamp like RTP so we can maintain synchronisation.

So with that, we wind up with these fields:

Timestamp
Sample rate
Number of channels
Sample format

Timestamp

The timestamp field in RTP is basically measured in ticks of some clock of known frequency, e.g. for PCMU it is a 8kHz clock. It starts with some value, then increments up monotonically. Simple enough concept. If we make this frequency the sample rate of the audio stream, I think that will be good enough.

At 48kHz 16-bit stereo; data will be streaming at 192kbps. We can tolerate wrap-around, and at this data rate, we’d see a 16-bit counter overflow every ~341ms, which whilst not unworkable, is getting tight. Better to use a 32-bit counter for this, which would extend that overflow to over 6 hours.

Sample rate encoding

We can either support an integer field, or we can encode the rate somehow. An integer field would need a range up to 768k to support every rate ALSA supports. That’s another 32-bit integer. Or, we can be a bit clever: nearly every sample rate in common use is a harmonic of 8kHz or 11.025kHz, so we devise a scheme consisting of a “base” rate and multiplier. 48kHz? That’s 8kHz×6. 44.1kHz? That’s 11.025kHz×4.

If we restrict ourselves to those two base rates, we can support standard rates from 8kHz through to 1.4MHz by allocating a single bit to select 8kHz/11.025kHz and 7 bits for the multiplier: the selected sample rate is the base rate multiplied by the multipler incremented by one. We’re unlikely to use every single 8kHz step though. Wikipedia lists some common rates and as we go up, the steps get bigger, so let’s borrow 3 multiplier bits for a left-shift amount.

7 6 5 4 3 2 1 0
B S S S M M M M

B = Base rate: (0) 8000 Hz, (1) 11025 Hz
S = Shift amount
M = Multiplier - 1

Rate = (Base << S) * (M + 1)

Examples:
  00000000b (0x00): 8kHz
  00010000b (0x10): 16kHz
  10100000b (0xa0): 44.1kHz
  00100000b (0x20): 48kHz
  01010010b (0x52): 768kHz (ALSA limit)
  11111111b (0xff): 22.5792MHz (yes, insane)

Other settings

I primarily want to consider linear PCM types. Technically that includes unsigned PCM, but since that’s losslessly transcodable to signed PCM, we could ignore it. So we could just encode the number of bytes needed for a single channel sample, minus one. Thus 0 would be 8-bits; 1 would be 16-bits; 2 would be 32-bits and 3 would be 64-bits. That needs just two bits. For future-proofing, I’d probably earmark two extra bits; reserved for now, but might be used to indicate “compressed” (and possibly lossy) formats.

The remaining 4 bits could specify a number of channels, again minus 1 (mono would be 0, stereo 1, etc up to 16).

Packet type

For the sake of alignment, I might include a 16-bit identifier field so the packet can be recognised as being this custom audio format, and to allow multiplexing of in-band control messages, but I think the concept is there.

2020/05/26 by Redhatter (VK4MSL) Amateur Radio Bicycle Mobile Computing Emergency Communications Linux Development Open Source Projects Public Syndication Thinktank WICEN 0

5G nonsense

For the past 2 years now, there’s been quite a bit in the press about the next evolution of mobile telephony standards.

The 5G standard is supposed to bring with it higher speeds and greater user density handling. As with a lot of systems, “5G” itself, describes a family of standards… some concern the use of millimetre-wave communications for tower-to-handset communications, some cover the communications channels for more modest frequencies in the high UHF bands.

One thing that I really can’t get my head around is the so-called claims of health effects.

Now, these are as old as radio communications itself. And for sure, danger to radio transmissions does increase with frequency, proximity and transmit power. There is a reason why radio transmitter sites such as those that broadcast medium wave radio or television are fenced off: electrocution is a real risk at high power.

0G: glorified two-way radios

Mobile phones originally were little more than up-market cordless phones. They often were a luggable device if they were portable at all. Many were not, they were installed into a vehicle (hence “mobile”). No such thing as cell hand-over, and often incoming calls had to be manually switched.

Often the sets were half-duplex, and despite using a hand-set, would have a very distinctive “radio” feel to them, requiring the user use a call-sign when initiating a call, and pressing a push-to-talk button to switch between listening and talking modes.

These did not see much deployment outside the US or maybe Europe.

1G: cellular communications

Back in the late 80s, when AMPS mobile phones (1G) were little more than executive toys, there might not have been much press about, but I’m sure there’d be anecdotal evidence of people being concerned about “radiation”.

If any standard was going to cause problems, it’d have been 1G, since the sets generally used much higher transmit power to compensate for the lack of coverage. They were little more than glorified FM transceivers with a little digital control channel on the side which implemented the selective calling and cell hand-off.

This was the first standard we saw here in Australia, and was the first to be actually practical. Analogue services didn’t last that long, and because of the expense of running AMPS services, they were mostly an expensive luxury. So that did limit its up-take.

2G: voice goes digital

The next big change was 2G, which replaced the analogue FM voice channel and used digital modulation techniques. GSM (which used Gaussian Minimum Shift Keying) and CDMA (which used phase shift keying) encoded everything in a single digital transmission.

This meant audio could be compressed (with some loss in fidelity), and have forward error correction added to make the signal more robust to noise. The cells could handle more users than the 1G services could. Transmit power could be reduced, improving battery life and the sets became cheaper to make and services became more economical.

Then came all the claims that 2G was going to cause us to develop brain cancer.

Now, many of those 2G services started popping up in the mid 90s… has there been a mass pandemic of cancer cases? Nope! About the only thing GSM was bad for, was its ability to leak into any audio frequency circuit.

2G went through a few sub-revisions, but it basically was AMPS done digitally, so fundamentally worked much the same. A sore point was how data was handled. 2G and its predecessors all tried to emulate what the wired network was doing: establishing a dedicated circuit between callers.

The Internet was really starting to get popular, and people wanted a way to access it on the move. GPRS did allow for some of that, but it really didn’t work that well due to the way 2G saw the world, so things moved on.

3G: packet switching

The big change here was the move from “circuits” to sending data around in packets. This is more like how the Internet operates, and so it meant the services could better support an Internet connection.

Voice still went the old-fashioned way, dedicated circuits, since the QoS (quality of service) could be better maintained that way.

The cells could support more users than 2G could, and the packet mode meant mobile Internet finally became a “thing” for most people.

I don’t recall there being the same concern about health as there was for 2G… it was probably still simmering below the surface. Services were deployed further afield and of course, the uptake continued.

4G: bye bye circuit switching

4G or LTE is the current standard that most of us are using. The biggest change is it ditches the circuit switching used in 1G, 2G and 3G. Voice is done using VoLTE… basically the voice call is sent the same way calls are routed over the Internet.

The cell towers are no longer trying to keep a “circuit” connected to your phone as you move around, instead it’s just directing packets. It’s your handset’s problem to sort out whether it heard a given packet already, or re-arrange incoming packets if they arrive out-of-order.

To make this work, obviously the latency inherent in 3G had to be addressed. As a sweetener, the speeds were bumped up, and the voice CODEC could be updated, so we gained wide-band voice calls. (Pity Bluetooth hasn’t kept up!)

5G: new frequencies, higher speed, smaller cells

So far, the cellular standards have largely co-existed in the same frequency bands. 4G actually varies quite a bit in frequency, but basically there are bands from the low UHF around 410MHz right up to microwave at 2600MHz.

Higher frequencies

5G has been contentious because some implementations of it reach even higher. Frequency Range 1 used in the 5G NR standard is basically much the same as 4G, but frequency range 2 soars as high as 40GHz.

Now, in terms of the electromagnetic spectrum, compared to other forms of radiation that we rely on for survival (and have done ever since life first began on this planet), this might as well be DC!

Infrared radiation, which is the very bottom of the “light” spectrum, starts at 300GHz. At these frequencies, we typically forget about frequencies, and instead consider wavelengths (1mm in this case). Visible light is even higher, 430THz (yes, that’s T for tera!).

Now, where do we start to worry about radiation? The nasty stuff begins with ultraviolet radiation, specifically UVC which is at a dizzying 1.1PHz (yes, that’s peta-hertz). It’s worth noting that UVB, which is a little lower in frequency can cause problems when exposure is excessive… however none is dangerous too, you actually need UVB exposure on your body to produce vitamin D for survival!

Dielectric heating

So that’s where the danger is in terms of frequency. I did mention that danger also increases with power… this is why microwave ovens, which typically operate at a fairly modest 2.4GHz frequency, pose a risk.

No, they won’t make you develop cancer, but the danger there is when there’s a lot of power, it can cause dielectric heating. That is, it causes molecules to move around, and in doing so, collide transferring energy which is then given off as heat. It happens at all frequencies in the EM spectrum, but it starts to become more practical at microwave frequencies.

To do something like cook dinner, a microwave oven bombards your food with hundreds of watts of RF energy at it. The microwave has a thick RF shield around it for a reason! If that shield is doing what it should, you might be exposed to no more than a watt of energy escaping the shield. Not enough to cause any significant heating.

I hear that if you put a 4W power amp on a 2.4GHz WiFi access point and put your hand in front of the antenna, you can “feel” framing packets. (Never tried this myself.) That’s pretty high power for most microwave links, and would be many orders of magnitude more than what any cell phone would be capable of.

Verdict: not a health risk

In my view, there’s practically no risk in terms of health effects from 5G. I expect my reasoning above will be thoroughly rubbished by those who are protesting against the roll-out.

However, that does not mean I am in favour of 5G.

The case against 5G

So I seem to be sticking up for 5G above, but let me make one thing abundantly clear, for us here in Australia, I do not think 5G is the “right” thing for us to use. It’s perfectly safe in terms of health effects, but simply the wrong tool for the job.

Small cells

Did I mention before the cells were smaller? Compared to its predecessors, 5G cells are tiny! The whole point of 5G was to serve a large number of users in a small area. Think of 10s of thousands of people crammed into a single stadium (okay, once COVID-19 is put to bed). That’s the use case for 5G.

5G’s range when deployed on the lower bands, is about on par with 4G. Maybe a little better in certain ideal conditions with higher speeds. This is likely the variant we’re most likely to see outside of major city CBDs. How reliable it is at that higher speed remains to be seen, as there’s a crazy amount of DSP going on to make stuff work at those data rates.

5G when deployed with mmWave bands, barely makes 500 metres. This will make deployment in the suburbs prohibitively expensive. Outdoor Wi-Fi or WiMAX might not be as fast, but would be more cost-effective!

Processor load

Did I mention about the crazy amount of DSP going on? To process data streams that exceed 1Gbps, you’re doing a lot of processing to extract the data out of the radio signal. 5G leans heavily on MIMO for its higher speeds, basically dividing the high-rate stream into parts which are directed to separate antennas. This reduces the bandwidth needed to achieve a high data rate, but it does make processing the signal at the far end more complex.

Consequently, the current crop of 5G handsets run hot. How hot? Well, subject them to 29.5°C, and they shut down! Now, think about the weather we get in this country? How many days have we experienced lately where 29°C has been a daily minimum, not a maximum?

5G isn’t the future for Australia

We need a wireless standard that goes the distance, and can take the heat! 5G is not looking so great in this marathon race. Personally, I’d like to see more investment into the 4G services and getting those rolled out to more locations. There’s plenty of locations that are less than a day’s drive from most capital cities, where mobile coverage is next to useless.

Plenty of modern 4GX handsets also suffer technical elitism… they see 3G services, but then refuse to talk to them, instead dropping to -1G: brick emulation. There’s a reason I stick by my rather ancient ZTE T83 and why I had high hopes for the Kite.

I think for the most part, many of the wireless standards we see have been driven by Europe and Asia, both areas with high population densities and relatively cool annual temperatures.

It saddens me when I hear Telstra tell everybody that they “aspire” to be a technology company, when back in the early 90s, Telecom Australia very much was a technology company, and a well respected trail-blazing one at that! It’s time they pulled their finger out and returned to those days.

2020/05/22 by Redhatter (VK4MSL) Computing Rants Thinktank 0

COVIDSafe for older devices?

So, the other day I pondered about whether BlueTrace could be ported to an older device, or somehow re-implemented so it would be compatible with older phones.

The Australian Government has released their version of TraceTogether, COVIDSafe, which is available for newer devices on the Google and Apple application repositories. It suffers a number of technical issues, one glaring one being that even on devices it theoretically supports, it doesn’t work properly unless you have it running in the foreground and your phone unlocked!

Well, there’s a fail right there! Lots of people, actually need to be able to lock their phones. (e.g. a condition of their employment, preventing pocket dials, saving battery life, etc…)

My phone, will never run COVIDSafe, as provided. Even compiling it for Android 4.1 won’t be enough, it uses Bluetooth Low Energy, which is a Bluetooth 4.0 feature. However, the government did one thing right, they have published the source code. A quick fish-eye over the diff against TraceTogether, suggests the changes are largely superficial.

Interestingly, although the original code is GPLv3, our government has decided to supply their own license. I’m not sure how legal that is. Others have questioned this too.

opentrace-covidsafe.diff.gzDownload

So, maybe I can run it after all? All I need is a device that can do BLE. That then “phones home” somehow, to retrieve tokens or upload data. Newer phones (almost anything Android-based) usually can do WiFi hotspot, which would work fine with a ESP32.

Older phones don’t have WiFi at all, but many can still provide an Internet connection over a Bluetooth link, likely via the LAN Access Profile. I think this would mean my “token” would need to negotiate HTTPS itself. Not fun on a MCU, but I suspect someone has possibly done it already on ESP32.

Nordic platforms are another option if we go the pure Bluetooth route. I have two nRF52840-DK boards kicking around here, bought for OpenThread development, but not yet in use. A nicety is these do have a holder for a CR2032 cell, so can operate battery-powered.

Either way, I think it important that the chosen platform be:

easily available through usual channels
cheap
hackable, so the devices can be re-purposed after this COVID-19 nonsense blows over

A first step might be to see if COVIDSafe can be cleaved in two… with the BLE part running on a ESP32 or nRF52840, and the HTTPS part running on my Android phone. Also useful, would be some sort of staging server so I can test my code without exposing things. Not sure if there is such a beast publicly available that we can all make use of.

Guess that’ll be the next bit to look at.

2020/05/12 by Redhatter (VK4MSL) Computing Open Source Public Syndication Rants Thinktank 0