Archive for the ‘Microwave’ Category

linux.conf.au 2016 talk


Download Watch on Youtube

A few weeks ago I did a talk on my Microwave project at linux.conf.au it took me a while to be brave enough to watch myself and it wasn’t as bad as I thought. The talk was certainly well received, the feedback was positive and useful, there were about 150 people in the room and the youtube copy has clocked almost 400 views so far. I also got a writeup published by Linux Weekly News.

There is a lot I am taking away from the process, I don’t think I have been so unprepared in my life but managed to get away with it. The response from people was far more favourable than I expected, in particular I was surprised that most of the questions have engaged at the concept level rather than the implementation details. A few people commented that they saw me settle and become less nervous a short way into the talk, in reality I realised I was blowing through the material far too quickly and just tried to slow down, I think I did settle a bit once the questions started flowing though. I also did not understand the realities of a large group practising passive listening, for example people listening while playing with their laptop or phone, rather disconcerting when you look up and feel that nobody is paying attention.

Feedback

Some interesting feedback was people seeing possibilities to use the microwave for things that microwaves are not customarily used for, I confess I had been blind to this. In particular tempering chocolate and sous-vide cooking both require holding the temperature to set level for a prolonged period. Other precise heating processes like heating sugar are also interesting options.

Several people suggested just doing the electronic work and abandoning or delaying the mechanical modifications until the next model. This was something I looked at early on and decided against but the arguments are certainly strong enough that I will be reconsidering it.

At the end of the talk I conducted a price point survey which showed that many people felt the product was worth $500 AUD but baulked and $1000 AUD. Which doesn’t mean that I wouldn’t find sales at the higher level but life is easier closer to $500. These prices include compensation for the increased risk of the kickstarter process.

Discussions on eevblog raised that solid state microwaves are coming. I thought that they would be about ten years out but it looks like it will probably be two to three years, manufacturers are advertising that commercial units will be available at the end of the year. This is interesting and sets a time limit to the project but I don’t feel it is a huge threat at this point. It may actually be a benefit in the long run.

Most of the implementation feedback was positive. One LWN commenter specifically noted that they generally disliked the IOT trend but felt that I was doing in the right way. Other LWN comments talked about how the modifications seemed well planned rather than a trend of adding “smarts” for no real benefit.

And completely unrelated to the talk, I also stumbled across an interesting reddit topic wishing that the microwave could recognise QR or bar codes and they automatically apply the proper heating process.

Next steps

My next step is a review process, one I am rather trepidatious about.

When I started the project I recognised the reality that only 1/10 projects succeeds. In practice the stats only count projects that get fairly big and on the government’s radar, a stage I am not yet at. So success is probably no more than a 1% chance.

Naturally my project is better than those that failed, I have a realistic project, good market etc. etc… factors that I am sure the 99% had in their favour too.

The reality is that like poker it is very easy to let emotions dominate and commit you to play on well beyond when you should fold. To try and counter this I have set up pre-established fold points to step back and review.

This is probably my biggest re-evaluation point so more dry planning posts coming up, I will probably also get some independent evaluation to help distance myself.

Packaging an automated login

xlogin

Having a Linux system automatically log in to a graphical program on boot is surprisingly difficult. Common solutions involve setting up a display manager with custom configuration and it gets messier from there. Fortunately there is a better way, xlogin uses systemd to launch X for a given user.

The developer describes it as a stop-gap workaround but after four years it is still a leading solution. xlogin consists of two systemd services, a launching wrapper script, and a xinitrc config tweak. If it is a hack it is a very elegant one, the four files together come to just forty lines (31 if you remove comments and whitespace).

Unfortunately it’s not packaged for Debian, while shovelling some files on to the disk works as a short term measure in the long run I really need it to be packaged, it greatly helps the image generation and allows long term maintenance. So I prepared a quick ugly package. It currently has some issues that like bad source package generation don’t impact me but need to be fixed, I’ll clean it up and look and submitting it in a few weeks.

Package Managing

To feed the packages in to multistrap requires a Debian repository. Fundamentally this is a http or ftp directory tree with a few specially formatted files. There are a plethora of tools to assist creating this but as is common when there are lots of tools doing the same job, none of them stand out as been considerably better than the others. I chose to use reprepro, it isn’t easy to set up but blindly following online guides worked for me.

Keyring Managing

Debian signs all of it’s packages as a basic assurance measure. The Debian tools take some convincing to run unsigned packages so it is easier when building your own packages to sign them too.

Signing is the easy half. You generate a gpg key, feed it to reprepro and it signs all the packages it delivers.

Where things get a bit more complex is getting the public key in to the client computer so that it can verify the key. The quick solution is to push the key in to apt-key when generating the image. This works but is difficult to maintain.

The more complete solution, which Debian uses for it’s own packages, is to create a keyring containing all the valid keys. This keyring is then packaged and distributed through the package management system. Structuring it this ways allows keys to be added or revoked as required by pushing a package update. Doubling down the complexity, managing the keyring package is a cluster of programs called jetring which provide tracability of changes.

I built my own keyring package, lodlabs-keyring based on debian-archive-keyring which I distribute through my development package manager. With this setup I can feed multistrap custom packages at will.

A quick note, using this technique multistrap must be able to acquire the keyring package itself. So the image generating machine must tie apt in to the private repository and have the keyring installed.

Creating your own keyring package

For a very small simple package creating your own keyring is a bit of work.

For starters, you need the basics:

apt-get build-depends debian-archive-keyring
apt-get source debian-archive-keyring

The debian-archive-keyring has a few directories:

  • keyrings:
    This contains the generated keyrings, the end products. They are created by the Makefile.
  • active-keys, removed-keys, team-members:
    Each of these directories contains a collection of keys.
    The keys are of a custom file format, generated by jetring from a gpg key.
    Instructions for creating a key are in README.maintainer.
    There is also an index file with a checksum for each key, this can be generated by jetring-accept.
    Finally there is an index.gpg file which signs the index, this can be generated by jetring-signindex.

    • active-keys:
      This keyring is used to verify the archive packages and is distributed in the generated package.
    • removed-keys:
      This keyring is used to revoke previous active keys and is distributed in the generated package.
    • team-members:
      This keyring is used by the package generation to verify the active and removed keyrings. It is not distributed outside the package.

To proceed you are going to need two gpg keys, you con probably use the same key twice but it wouldn’t be advisable. I generated two different subkeys following the instructions here. The active subkey is the one used to set up reprepro and sign your packages. The team subkey is your personal signing key.

Push the personal key into the team keychain, then the reprepro key into the active keychain by following the instructions in debian-archive-keyring’s README.maintainer.

Once your keys are in the packaging key directories, delete all the other keys in active-keys and team-members. Edit the index files so that only your key entry remains. Then resign the index by running jetring-signindex over each folder.

You can also delete all the keys in removed-keys, create an empty index file and sign it with jetring-signindex.

Now if you run `make` it should generate new keyring files only containing your keys.

To complete the package it will need to be renamed. Edit all the debian files, changing every instance of debian-archive-keyring to your-keyring. The changelog, copyright and control files will all need to have portions partially rewritten. The debian-archive-keyring script files in the debian folder will need to be renamed and the debian-archive-keyring instances in the Makefile will all need to be changed.

The generated keyring files must be signed, run
gpg --armor --detach-sign keyrings/your-removed-keys.gpg

Finally invoking `debuild -b -uc -us` should spit out your-keyring_<year>.<month>_all.deb.

Screen Interface Prototype

While I have been rather negligent with my blog updates I have been kicking goals with progress on the Grid-Eye thermal sensor, BananaPi screens and the user interface. Of these it is user interface that I am going to blather about here.

My primary goal of this project is to improve the microwave user interface, shifting away from four character seven segment displays to a more interactive fully featured display.

Everything else, most of the work, is to support and implement this improvement. As I am now up to playing with the screens, selecting screen sizes and touch interfaces it seemed worthwhile to spend a bit of time considering what the GUI will actually look like.

I did a few pages of pencil sketches, useful to work through a wide variety of ideas.

Then I did a prototype implementation in HTML to iterate the better ideas. This prototype is below, it is a fully interactive webpage – some bits pretend to work, other bits are stubbed out.

I would really appreciate it if people would play and give feedback. It is designed for a fixed screen size of 480×800 pixels, the primary user interface will be finger on a touchscreen, there will also be general web browser access for PCs and portable devices.

View in new tab/window

The source code is available on github, it is prototype code so there are more than few shortcuts and lots of poor practices.

My current design guidelines are:

  • Intuitive to use
    • No instruction manual or help pages
    • No advanced touch interfaces (sliding, multitouch etc.)
    • Large, obvious, touch targets
    • Accessible colour scheme and aria support
  • Forgiving of mistakes
  • Not too hideously ugly
Return top