Archive for the ‘Engineering’ Category

Down With Apps

Monday, March 8th, 2021

So, one of the things that really irritates me is when a company only offers functionality via apps. This is especially a problem with IOT devices, most of which will end up in the dump in a few years when there’s no way to install the app that enables them to be configured any more, but it’s also a problem with functionality in general.

There’s some major problems with requiring functionality to require a app to be installed

A: There’s some serious privacy concerns. Most people don’t read the list of privileges the app will have, and they can easily include access to the camera, filesystem, radio modem, etc. Even if the app just sends TCP traffic, the user seldom has much control over what that traffic includes, and that traffic can definitely be identifying

B: It is yet another way that the modern world tries to get you locked into upgrade train. At some point the app developers will stop supporting older operating systems and you will be forced to buy a new phone just to run a app you’re required to have in order to access $FUNCTIONALITY.

C: It is yet another way the modern world tries to get you locked into the throwaway economy, in that the manufacturers will stop maintaining apps for devices and they will become unavailable, at which point the devices will be unconfigurable and have to be replaced.

D: Most of the apps I’ve seen are ridiculously bloated. Taco bell needs 100 megs so I can order a taco? Many of them are also massively wasteful of CPU and/or poorly written. Most of them have at least one bug that will crash the app.

E: As a side effect of #D, there’s no chance that the developers know all the library code that’s in all the apps, or that the end users do. So, the apps also act as a security concern in that they may include libraries with security weaknesses that not even the developers are likely to know about

F: Apps are – generally – not friendly to the blind. There’s also the question of whether we should *require* people to have a smartphone in order to participate in the modern world. A particular company I’d like to underline who has done this but has absolutely no excuse for it is Venmo, who has chosen to remove the payment functionality from their web site in order to force users to install their app – probably partially because they can then sell private data about those users. I have reported them to the ADA in the hopes that it gets them forced to return the functionality to their web site.

In general, I am against the idea of installable apps in favor of web sites. A lot of apps are really just web sites wrapped, and with html5 increasingly we can get access to specialized hardware like GPS and video cameras without needing to install anything.

It strikes me as a dystopian world that requires people to own, not just a smartphone, but perpetually newer models of smartphone in order to participate. I think as end users we should collectively refuse to install apps whenever possible.

Another subject of dystopia that I should discuss in the future is the forced “upgrade” to newer and often worse versions of user interfaces.

Elon Musk and Mars

Saturday, February 6th, 2021

So, several times over the years I’ve thought me and Elon Musk should sit down and have a discussion – which would probably, I readily admit, turn into a argument. But we have a lot of things in common, interest wise.

I am often struck by how Elon and Tesla both have the same sense of showmanship, and the same tendency to make utterly batshit claims occasionally.

Elon’s got some great ideas (reusable spacecraft, electric cars, possibly even underground transit) and some reeeeeally bad ones (hyperloop, semiballiastic orbital travel for point to point on earth). But I want today to address a particularly nutty idea he’s come up with – that we’d be able to do a manned Mars mission by 2026. (Claim made here).

This is absolutely true – if we don’t mind that it’s a one way trip, and that we’ll be sending people to die on Mars in a few weeks or months.

However, the tradition in American spaceflight is we don’t consider the crew expendable. Which means a more reasonable timeline is 2046 if we use conventional fuels, or 2036 if we use a NERVA.

Now, I know in general the world is against NERVAs, and I don’t deny that they’re a bit risky – if we did use a NERVA we’d probably have to send up the fuel rods encapsulated in the best tech we could put them in, and assemble them in space. I do feel like various forces have overstated the risk of using nuclear fueled spacecraft, and that’s another whole topic. But, I want to make the case for using a NERVA here.

If we used a NERVA, we would not need combustible fuel, just ‘reaction mass’. THis means any liquid or gas that can be liquified would do! This makes it easy to guarantee a return flight, assuming the spacecraft arrives in one piece on mars, because you can

A: Use the same reactor fuel to run a reactor that compresses Mars’s atmosphere into the reaction mass tanks
B: Use the same reactor fuel to power heat & light onboard the spacecraft and a connected ‘Hab’ a la the Martian
C: It’s very likely a NERVA would not suffer from many of the ‘cold soak’ issues that a conventional rocket engine does, because NERVA designs often involve very few moving parts and by definition the reactor itself is going to get the whole system plenty hot by the time the jet fires

However, given that we’ve shelved NERVA technology, it would still be many years, even if we used a NERVA, before we could talk about going to mars and returning. I don’t know if Musk is outrageously optimistic, or if he’s doing the ‘just one more hill and we’ll be at the top of the mountain’ technique of pushing humanity along.

Anyway, without a NERVA, let’s talk about the challenges, so we understand why 2026 is ludicrous

#1: With a combustible fuel rocket, carrying enough fuel for a two way journey is a non-starter. It makes the fuel load *the square* of the amount you need for a one way journey, because you must carry the fuel to move the fuel.
#2: With a combustible fuel rocket, generally after a burn adequate to reach escape velocity on earth, some maintenance must be done before another burn can occur. Very likely this would have to be done in orbit above mars. Fixing things in space is *tricky* and takes months of simulations and practice to pull off.
#3: With a combustible fuel rocket, a very real concern is ‘cold soak’.

a) Most spacecraft to date have avoided the challenge of trying to ignite something that has been sitting at -200 degrees by using hypergolic fuels – that is to say, fuels that when two dissimilar parts are mixed together, ignition happens automatically. However, hypergolic fuels are much less efficient than oxidized fuels AND they’re incredibly toxic. They are not suitable for a escape velocity rocket anywhere much bigger than the moon.
b) If not using hypergolic fuels, you actually have to figure out starting up the fuel and oxidizer pumps, then igniting the mix coming out of them. Bunch of moving parts to get all working together.

#4: We’ve often spoken of using a combustible fuel rocket and “making the fuel on mars”. If we can find water, we can electrolyze it and make hydrogen and oxygen, then liquify them and make fuel. OK, I agree, all that is true, but there’s a lot less sunlight falling on Mars than on Earth. Doing that with a solar array is going to take a loooong time (and at the same time we’ll also have to make enough power for heat & light for the crew). So we’re probably going to have to send a nuclear reactor to Mars anyway, just to make the fuel, unless we want to try to keep men alive on Mars for a year on our first foray – something that is also likely to end in a dead crew.

Tuesday, August 4th, 2020

One of the projects I ponder from time to time is making a 3D printer big enough to print a house. I’m really curious whether it would be possible to take this technology further than it’s already been taken – in particular I’m interested about the possibility of having the printer I electrodeposit or just plain insert rebar at appropriate places, and I’m also curious, how cheap could you make such a beast?

Obviously it’s going to have some expensive parts – a high pressure concrete pump – but mostly it’s just some ropes, some big gear motors, and some sort of scaffolding to hang the whole thing off of.

Another project I have joked about many times – the ConeDrone, a series of remote controlled cars to move around traffic cones so we don’t spend a hour before every construction project shutting down the road and another hour bringing it back online – involves precision locating via RF, which would also figure largely in a 3D printer big enough to print a house.

I should probably start out by making a *small* 3D printer just to get a sense of the problems involved. It looks easy enough, but I suspect like so many things of that nature, the devil is in the details.

I do also sometimes ponder subtractive 3D printing i.e. CNC – watching the amazing work on the Marble Machine 2.0 has made me really appriciate how far this technology has come, and I may get some subtractive 3D gear for the solar tracker project.

Solar adventures

Monday, August 3rd, 2020

So, earlier in the year, when COVID was just starting to ramp up and also when coincidentally I was in the midst of about as manic as I let myself get these days, I – in perhaps a moment of unreasonable paranoia – decided I wanted a backup generator. Except, I wanted a backup generator that would actually be useful if social unrest or other issues resulted in gasoline being difficult to get. (Not that many gas stations have backup generators, so even just a city-wide blackout could the cause this, and we’ve certainly had our share of blackouts since moving to this house, including one !5-day! outage)

So, I did what seemed the most reasonable thing to me at the time, which was buy a bunch of solar panels, some lead acid batteries, and a couple of big inverters.

It has been working pretty well – my basement’s been running off it since March, I think, and I haven’t run out of power yet – however, at the moment the panels are just lying in the front yard. If my math is correct, this is only giving me 30% of the power i’d get if they were on a two axis tracker.

So, I’ve been slowly working through various designs to try to figure out how I want to do tracking with them. I’d like to do something cheap-ish and DIY, and I’m fine with the east/west axis being manual but I want the RA axis to be automatic. I was pondering something like a drawbridge with a winch, but lately I’m again favoring the idea of using a couple of large bearings (I like the idea of using wheel bearings and wheel hubs from a car for some reason) and a gear motor. But it may change designs again. I’ve been suffering from a certain extent of laziness surrounding it. Some of my problem is that I am not really that great at using 3D modelling software – I really need to sit down and learn, but I’m not really sure which software I want to use. I am increasingly thinking I need to buy a desktop application for this as I tried using several different web based solutions and all of them had serious performance issues. I do not think 3D modelling is really something that’s well suited to being a web app, especially in the post-flash world. Of course, maybe part of the problem is just my lack of 3D modelling skill..

Anyway, winter is coming, so I should probably put a little more effort into this. It’s easy to generate enough power to run your basement in the summer in Seattle.. we have very long sunny days. The winter, with it’s very short, cloudy days, is likely to be a good deal more challenging.

One thing that is very sasisfying about having thrown together a solar array – beyond that it worked on the first try and I was able to easily set up a raspberry pi to track energy in and out of various things – is that I can use it to charge my EV. Whatever wars we get up to over oil are therefore that much less my fault. It’s possibly the most effective protest of the US war machine I’ve ever come up with.

IOT problems

Sunday, August 2nd, 2020

So, one problem that we in general have with computers is that they are constantly in a state of growth and therefore it tends to be difficult to read files written 20 or 30 years ago because we don’t have anything remaining that can either handle the physical or logical format. (This makes me wonder if anyone has made something like the 7 layer model for data storage)

Anyway, one upcoming problem is that we lately are doing a lot of IOT devices – and a whole lot of these are going to be in landfills in ten years. The basic problem is that the people coding for them have fallen in love with the latest moronic fad, which is to have a ‘app’ to set up everything.

We need to have a *universal* configuration language that runs over bluetooth – someone should have a working group together. Or, we could just stream HTML over bluetooth – hm, that seems like a really good idea now that I mention it. Anyway, I also am pondering if most devices should just use bluetooth to negotiate the initial internet connection and then be configured via a web page. That seems like it might be best.

What isn’t best, what is in fact awful, is to have custom code, a dedicated app, for each device to be configured. Some of the obvious problems with this:

1) It requires the user to have a device that the app will run on. In 20 years there may be no android or IOS devices left because someone may have written a much better operating system

2) There’s also some version issues. As per usual the developers don’t write things to run on all versions, and it’s very likely that future versions will also be incompatible

3) This requires the developers of the hardware to continue releasing software – in some cases the developers may not even exist, and even if they do exist capitalism says it won’t be profitable to continue to support devices that are even a few years old so I doubt if we’re going to continue to see new versions of configuration tools

So, here’s what I think tehy should be doing

#1: We need a standard communication protocol for bluetooth for configuring all devices that are configured via bluetooth or BLE. Bluetooth working group, I’m looking at you. If you can charge $8000 per device for people to have your logo, you can do less of a halfass job at telling them not to make devices that won’t be configurable in a few years because the apps will no longer be maintained

#2: We need to have a agreement that whenever possible we’re going to use a standard web browser to configure devices. You can still make custom apps that do it as well, but you should document the API and have a plain ol’ javascript version of it so those of us who don’t want to deal with your apps can still use our devices

#3: Whenever possible you should make it so that your device can be maintained locally without your cloud service. Ideal ways to do this include docker and kubernetes containers that run your service that the customer can install on their local hardware, open source descriptions of your protocols, etc.

#4: You should publish schematics, source code, and whatnot for your products – both allowing users to change the basic functionality and publish new and better versions of the firmware, and allowing them to look for security holes and design flaws. In a lot of cases, IOT devices can cause a lot of damage – you all need to be building equipment we can trust.

I’m currently in the process of working on firmware for a IOT device, and it has really made me think about how poor a job humans are doing on IOT in general right now.

Another thing I’d like to mention, and this in particular is aimed at ORbit’s B-Hyve. Whenever possible, *DO NOT* waste the user’s time. If you do not *need* to upgrade the firmware to be able to continue, *don’t*. If you must upgrade the firmware, try to do it over the internet rather than BLE – at the very least, kick into bluetooth classic in order to be able to get halfway decent amounts of bandwidth.

(B-Hyve is in many, many ways a example of how not to, when it comes to IOT devices. It’s a great idea, and the hardware is well done, but the software is *awful* in a very long list of ways)