Archive for the ‘Microwave’ Category

linux​.conf​.au 2016 talk

Down­load Watch on Youtube

A few weeks ago I did a talk on my Microwave pro­ject 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 cer­tainly well received, the feed­back was pos­it­ive and use­ful, there were about 150 people in the room and the you­tube copy has clocked almost 400 views so far. I also got a writeup pub­lished by Linux Weekly News.

There is a lot I am tak­ing away from the pro­cess, I don’t think I have been so unpre­pared in my life but man­aged to get away with it. The response from people was far more favour­able than I expec­ted, in par­tic­u­lar I was sur­prised that most of the ques­tions have engaged at the concept level rather than the imple­ment­a­tion details. A few people com­men­ted that they saw me settle and become less nervous a short way into the talk, in real­ity I real­ised I was blow­ing through the mater­ial far too quickly and just tried to slow down, I think I did settle a bit once the ques­tions star­ted flow­ing though. I also did not under­stand the real­it­ies of a large group prac­tising pass­ive listen­ing, for example people listen­ing while play­ing with their laptop or phone, rather dis­con­cert­ing when you look up and feel that nobody is pay­ing attention.


Some inter­est­ing feed­back was people see­ing pos­sib­il­it­ies to use the microwave for things that microwaves are not cus­tom­ar­ily used for, I con­fess I had been blind to this. In par­tic­u­lar tem­per­ing chocol­ate and sous-vide cook­ing both require hold­ing the tem­per­at­ure to set level for a pro­longed period. Other pre­cise heat­ing pro­cesses like heat­ing sugar are also inter­est­ing options.

Sev­eral people sug­ges­ted just doing the elec­tronic work and abandon­ing or delay­ing the mech­an­ical modi­fic­a­tions until the next model. This was some­thing I looked at early on and decided against but the argu­ments are cer­tainly strong enough that I will be recon­sid­er­ing it.

At the end of the talk I con­duc­ted a price point sur­vey 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 com­pens­a­tion for the increased risk of the kick­starter process.

Dis­cus­sions on eevb­log raised that solid state microwaves are com­ing. I thought that they would be about ten years out but it looks like it will prob­ably be two to three years, man­u­fac­tur­ers are advert­ising that com­mer­cial units will be avail­able at the end of the year. This is inter­est­ing and sets a time limit to the pro­ject but I don’t feel it is a huge threat at this point. It may actu­ally be a bene­fit in the long run.

Most of the imple­ment­a­tion feed­back was pos­it­ive. One LWN com­menter spe­cific­ally noted that they gen­er­ally dis­liked the IOT trend but felt that I was doing in the right way. Other LWN com­ments talked about how the modi­fic­a­tions seemed well planned rather than a trend of adding “smarts” for no real benefit.

And com­pletely unre­lated to the talk, I also stumbled across an inter­est­ing red­dit topic wish­ing that the microwave could recog­nise QR or bar codes and they auto­mat­ic­ally apply the proper heat­ing process.

Next steps

My next step is a review pro­cess, one I am rather trep­id­a­tious about.

When I star­ted the pro­ject I recog­nised the real­ity that only 1/10 pro­jects suc­ceeds. In prac­tice the stats only count pro­jects that get fairly big and on the government’s radar, a stage I am not yet at. So suc­cess is prob­ably no more than a 1% chance.

Nat­ur­ally my pro­ject is bet­ter than those that failed, I have a real­istic pro­ject, good mar­ket etc. etc… factors that I am sure the 99% had in their favour too.

The real­ity is that like poker it is very easy to let emo­tions dom­in­ate and com­mit you to play on well bey­ond when you should fold. To try and counter this I have set up pre-established fold points to step back and review.

This is prob­ably my biggest re-evaluation point so more dry plan­ning posts com­ing up, I will prob­ably also get some inde­pend­ent eval­u­ation to help dis­tance myself.

Packaging an automated login


Hav­ing a Linux sys­tem auto­mat­ic­ally log in to a graph­ical pro­gram on boot is sur­pris­ingly dif­fi­cult. Com­mon solu­tions involve set­ting up a dis­play man­ager with cus­tom con­fig­ur­a­tion and it gets messier from there. For­tu­nately there is a bet­ter way, xlo­gin uses sys­temd to launch X for a given user.

The developer describes it as a stop-gap work­around but after four years it is still a lead­ing solu­tion. xlo­gin con­sists of two sys­temd ser­vices, a launch­ing wrap­per script, and a xinitrc con­fig tweak. If it is a hack it is a very eleg­ant one, the four files together come to just forty lines (31 if you remove com­ments and whitespace).

Unfor­tu­nately it’s not pack­aged for Debian, while shov­el­ling some files on to the disk works as a short term meas­ure in the long run I really need it to be pack­aged, it greatly helps the image gen­er­a­tion and allows long term main­ten­ance. So I pre­pared a quick ugly pack­age. It cur­rently has some issues that like bad source pack­age gen­er­a­tion don’t impact me but need to be fixed, I’ll clean it up and look and sub­mit­ting it in a few weeks.

Pack­age Managing

To feed the pack­ages in to multistrap requires a Debian repos­it­ory. Fun­da­ment­ally this is a http or ftp dir­ect­ory tree with a few spe­cially format­ted files. There are a pleth­ora of tools to assist cre­at­ing this but as is com­mon when there are lots of tools doing the same job, none of them stand out as been con­sid­er­ably bet­ter than the oth­ers. I chose to use reprepro, it isn’t easy to set up but blindly fol­low­ing online guides worked for me.

Keyring Man­aging

Debian signs all of it’s pack­ages as a basic assur­ance meas­ure. The Debian tools take some con­vin­cing to run unsigned pack­ages so it is easier when build­ing your own pack­ages to sign them too.

Sign­ing is the easy half. You gen­er­ate a gpg key, feed it to reprepro and it signs all the pack­ages it delivers.

Where things get a bit more com­plex is get­ting the pub­lic key in to the cli­ent com­puter so that it can verify the key. The quick solu­tion is to push the key in to apt-key when gen­er­at­ing the image. This works but is dif­fi­cult to maintain.

The more com­plete solu­tion, which Debian uses for it’s own pack­ages, is to cre­ate a keyring con­tain­ing all the valid keys. This keyring is then pack­aged and dis­trib­uted through the pack­age man­age­ment sys­tem. Struc­tur­ing it this ways allows keys to be added or revoked as required by push­ing a pack­age update. Doub­ling down the com­plex­ity, man­aging the keyring pack­age is a cluster of pro­grams called jet­ring which provide tracab­il­ity of changes.

I built my own keyring pack­age, lodlabs-keyring based on debian-archive-keyring which I dis­trib­ute through my devel­op­ment pack­age man­ager. With this setup I can feed multistrap cus­tom pack­ages at will.

A quick note, using this tech­nique multistrap must be able to acquire the keyring pack­age itself. So the image gen­er­at­ing machine must tie apt in to the private repos­it­ory and have the keyring installed.

Cre­at­ing your own keyring package

For a very small simple pack­age cre­at­ing 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 con­tains the gen­er­ated keyrings, the end products. They are cre­ated by the Makefile.
  • active-keys, removed-keys, team-members:
    Each of these dir­ect­or­ies con­tains a col­lec­tion of keys.
    The keys are of a cus­tom file format, gen­er­ated by jet­ring from a gpg key.
    Instruc­tions for cre­at­ing a key are in README.maintainer.
    There is also an index file with a check­sum for each key, this can be gen­er­ated by jetring-accept.
    Finally there is an index.gpg file which signs the index, this can be gen­er­ated by jetring-signindex.

    • active-keys:
      This keyring is used to verify the archive pack­ages and is dis­trib­uted in the gen­er­ated package.
    • removed-keys:
      This keyring is used to revoke pre­vi­ous act­ive keys and is dis­trib­uted in the gen­er­ated package.
    • team-members:
      This keyring is used by the pack­age gen­er­a­tion to verify the act­ive and removed keyrings. It is not dis­trib­uted out­side the package.

To pro­ceed you are going to need two gpg keys, you con prob­ably use the same key twice but it wouldn’t be advis­able. I gen­er­ated two dif­fer­ent sub­keys fol­low­ing the instruc­tions here. The act­ive sub­key is the one used to set up reprepro and sign your pack­ages. The team sub­key is your per­sonal sign­ing key.

Push the per­sonal key into the team key­chain, then the reprepro key into the act­ive key­chain by fol­low­ing the instruc­tions in debian-archive-keyring’s README.maintainer.

Once your keys are in the pack­aging key dir­ect­or­ies, 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 run­ning jetring-signindex over each folder.

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

Now if you run ‘make‘ it should gen­er­ate new keyring files only con­tain­ing your keys.

To com­plete the pack­age it will need to be renamed. Edit all the debian files, chan­ging every instance of debian-archive-keyring to your-keyring. The changelog, copy­right and con­trol files will all need to have por­tions par­tially rewrit­ten. The debian-archive-keyring script files in the debian folder will need to be renamed and the debian-archive-keyring instances in the Make­file will all need to be changed.

The gen­er­ated keyring files must be signed, run
gpg --armor --detach-sign keyrings/your-removed-keys.gpg

Finally invok­ing ‘debuild –b –uc –us‘ should spit out your-keyring_<year>.<month>_all.deb.

Screen Interface Prototype

While I have been rather neg­li­gent with my blog updates I have been kick­ing goals with pro­gress on the Grid-Eye thermal sensor, BananaPi screens and the user inter­face. Of these it is user inter­face that I am going to blather about here.

My primary goal of this pro­ject is to improve the microwave user inter­face, shift­ing away from four char­ac­ter seven seg­ment dis­plays to a more inter­act­ive fully fea­tured display.

Everything else, most of the work, is to sup­port and imple­ment this improve­ment. As I am now up to play­ing with the screens, select­ing screen sizes and touch inter­faces it seemed worth­while to spend a bit of time con­sid­er­ing what the GUI will actu­ally look like.

I did a few pages of pen­cil sketches, use­ful to work through a wide vari­ety of ideas.

Then I did a pro­to­type imple­ment­a­tion in HTML to iter­ate the bet­ter ideas. This pro­to­type is below, it is a fully inter­act­ive webpage — some bits pre­tend to work, other bits are stubbed out.

I would really appre­ci­ate it if people would play and give feed­back. It is designed for a fixed screen size of 480×800 pixels, the primary user inter­face will be fin­ger on a touch­screen, there will also be gen­eral web browser access for PCs and port­able devices.

View in new tab/window

The source code is avail­able on git­hub, it is pro­to­type code so there are more than few short­cuts and lots of poor practices.

My cur­rent design guidelines are:

  • Intu­it­ive to use
    • No instruc­tion manual or help pages
    • No advanced touch inter­faces (slid­ing, mul­ti­t­ouch etc.)
    • Large, obvi­ous, touch targets
    • Access­ible col­our scheme and aria support
  • For­giv­ing of mistakes
  • Not too hideously ugly
Return top