Archive for the ‘Microwave’ Category 2016 talk

Down­load Watch on Youtube

A few weeks ago I did a talk on my Microwave project at 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­tain­ly well received, the feed­back was pos­i­tive and use­ful, there were about 150 peo­ple in the room and the youtube copy has clocked almost 400 views so far. I also got a write­up pub­lished by Lin­ux Week­ly News.

There is a lot I am tak­ing away from the process, I don’t think I have been so unpre­pared in my life but man­aged to get away with it. The response from peo­ple was far more favourable than I expect­ed, in par­tic­u­lar I was sur­prised that most of the ques­tions have engaged at the con­cept lev­el rather than the imple­men­ta­tion details. A few peo­ple com­ment­ed that they saw me set­tle and become less ner­vous a short way into the talk, in real­i­ty I realised I was blow­ing through the mate­r­i­al far too quick­ly and just tried to slow down, I think I did set­tle a bit once the ques­tions start­ed flow­ing though. I also did not under­stand the real­i­ties of a large group prac­tis­ing pas­sive lis­ten­ing, for exam­ple peo­ple lis­ten­ing while play­ing with their lap­top or phone, rather dis­con­cert­ing when you look up and feel that nobody is pay­ing atten­tion.


Some inter­est­ing feed­back was peo­ple see­ing pos­si­bil­i­ties to use the microwave for things that microwaves are not cus­tom­ar­i­ly used for, I con­fess I had been blind to this. In par­tic­u­lar tem­per­ing choco­late and sous-vide cook­ing both require hold­ing the tem­per­a­ture to set lev­el for a pro­longed peri­od. Oth­er pre­cise heat­ing process­es like heat­ing sug­ar are also inter­est­ing options.

Sev­er­al peo­ple sug­gest­ed just doing the elec­tron­ic work and aban­don­ing or delay­ing the mechan­i­cal mod­i­fi­ca­tions until the next mod­el. This was some­thing I looked at ear­ly on and decid­ed against but the argu­ments are cer­tain­ly strong enough that I will be recon­sid­er­ing it.

At the end of the talk I con­duct­ed a price point sur­vey which showed that many peo­ple felt the prod­uct was worth $500 AUD but baulked and $1000 AUD. Which doesn’t mean that I wouldn’t find sales at the high­er lev­el but life is eas­i­er clos­er to $500. These prices include com­pen­sa­tion for the increased risk of the kick­starter process.

Dis­cus­sions on eevblog raised that sol­id state microwaves are com­ing. I thought that they would be about ten years out but it looks like it will prob­a­bly be two to three years, man­u­fac­tur­ers are adver­tis­ing that com­mer­cial units will be avail­able at the end of the year. This is inter­est­ing and sets a time lim­it to the project but I don’t feel it is a huge threat at this point. It may actu­al­ly be a ben­e­fit in the long run.

Most of the imple­men­ta­tion feed­back was pos­i­tive. One LWN com­menter specif­i­cal­ly not­ed that they gen­er­al­ly dis­liked the IOT trend but felt that I was doing in the right way. Oth­er LWN com­ments talked about how the mod­i­fi­ca­tions seemed well planned rather than a trend of adding “smarts” for no real ben­e­fit.

And com­plete­ly unre­lat­ed to the talk, I also stum­bled across an inter­est­ing red­dit top­ic wish­ing that the microwave could recog­nise QR or bar codes and they auto­mat­i­cal­ly apply the prop­er heat­ing process.

Next steps

My next step is a review process, one I am rather trep­i­da­tious about.

When I start­ed the project I recog­nised the real­i­ty that only 1/10 projects suc­ceeds. In prac­tice the stats only count projects that get fair­ly big and on the government’s radar, a stage I am not yet at. So suc­cess is prob­a­bly no more than a 1% chance.

Nat­u­ral­ly my project is bet­ter than those that failed, I have a real­is­tic project, good mar­ket etc. etc… fac­tors that I am sure the 99% had in their favour too.

The real­i­ty is that like pok­er it is very easy to let emo­tions dom­i­nate and com­mit you to play on well beyond when you should fold. To try and counter this I have set up pre-estab­lished fold points to step back and review.

This is prob­a­bly my biggest re-eval­u­a­tion point so more dry plan­ning posts com­ing up, I will prob­a­bly also get some inde­pen­dent eval­u­a­tion to help dis­tance myself.

Packaging an automated login


Hav­ing a Lin­ux sys­tem auto­mat­i­cal­ly log in to a graph­i­cal pro­gram on boot is sur­pris­ing­ly dif­fi­cult. Com­mon solu­tions involve set­ting up a dis­play man­ag­er with cus­tom con­fig­u­ra­tion and it gets messier from there. For­tu­nate­ly there is a bet­ter way, xlo­gin uses sys­temd to launch X for a giv­en user.

The devel­op­er describes it as a stop-gap workaround 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 xini­trc con­fig tweak. If it is a hack it is a very ele­gant one, the four files togeth­er come to just forty lines (31 if you remove com­ments and white­space).

Unfor­tu­nate­ly it’s not pack­aged for Debian, while shov­el­ling some files on to the disk works as a short term mea­sure in the long run I real­ly need it to be pack­aged, it great­ly helps the image gen­er­a­tion and allows long term main­te­nance. So I pre­pared a quick ugly pack­age. It cur­rent­ly 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.

Package Managing

To feed the pack­ages in to mul­ti­strap requires a Debian repos­i­to­ry. Fun­da­men­tal­ly this is a http or ftp direc­to­ry tree with a few spe­cial­ly for­mat­ted files. There are a pletho­ra 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 repre­pro, it isn’t easy to set up but blind­ly fol­low­ing online guides worked for me.

Keyring Managing

Debian signs all of it’s pack­ages as a basic assur­ance mea­sure. The Debian tools take some con­vinc­ing to run unsigned pack­ages so it is eas­i­er 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 repre­pro and it signs all the pack­ages it deliv­ers.

Where things get a bit more com­plex is get­ting the pub­lic key in to the client com­put­er so that it can ver­i­fy 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 main­tain.

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. Dou­bling down the com­plex­i­ty, man­ag­ing the keyring pack­age is a clus­ter of pro­grams called jetring which pro­vide tra­ca­bil­i­ty of changes.

I built my own keyring pack­age, lod­labs-keyring based on debian-archive-keyring which I dis­trib­ute through my devel­op­ment pack­age man­ag­er. With this set­up I can feed mul­ti­strap cus­tom pack­ages at will.

A quick note, using this tech­nique mul­ti­strap must be able to acquire the keyring pack­age itself. So the image gen­er­at­ing machine must tie apt in to the pri­vate repos­i­to­ry and have the keyring installed.

Creating your own keyring package

For a very small sim­ple 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 direc­to­ries:

  • keyrings:
    This con­tains the gen­er­at­ed keyrings, the end prod­ucts. They are cre­at­ed by the Make­file.
  • active-keys, removed-keys, team-mem­bers:
    Each of these direc­to­ries con­tains a col­lec­tion of keys.
    The keys are of a cus­tom file for­mat, gen­er­at­ed by jetring 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­at­ed by jetring-accept.
    Final­ly there is an index.gpg file which signs the index, this can be gen­er­at­ed by jetring-signin­dex.
    • active-keys:
      This keyring is used to ver­i­fy the archive pack­ages and is dis­trib­uted in the gen­er­at­ed pack­age.
    • removed-keys:
      This keyring is used to revoke pre­vi­ous active keys and is dis­trib­uted in the gen­er­at­ed pack­age.
    • team-mem­bers:
      This keyring is used by the pack­age gen­er­a­tion to ver­i­fy the active and removed keyrings. It is not dis­trib­uted out­side the pack­age.

To pro­ceed you are going to need two gpg keys, you con prob­a­bly use the same key twice but it wouldn’t be advis­able. I gen­er­at­ed two dif­fer­ent sub­keys fol­low­ing the instruc­tions here. The active sub­key is the one used to set up repre­pro and sign your pack­ages. The team sub­key is your per­son­al sign­ing key.

Push the per­son­al key into the team key­chain, then the repre­pro key into the active key­chain by fol­low­ing the instruc­tions in debian-archive-keyring’s README.maintainer.

Once your keys are in the pack­ag­ing key direc­to­ries, delete all the oth­er keys in active-keys and team-mem­bers. Edit the index files so that only your key entry remains. Then resign the index by run­ning jetring-signin­dex over each fold­er.

You can also delete all the keys in removed-keys, cre­ate an emp­ty index file and sign it with jetring-signin­dex.

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, chang­ing every instance of debian-archive-keyring to your-keyring. The changel­og, copy­right and con­trol files will all need to have por­tions par­tial­ly rewrit­ten. The debian-archive-keyring script files in the debian fold­er will need to be renamed and the debian-archive-keyring instances in the Make­file will all need to be changed.

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

Final­ly 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 progress on the Grid-Eye ther­mal sen­sor, BananaPi screens and the user inter­face. Of these it is user inter­face that I am going to blath­er about here.

My pri­ma­ry goal of this project is to improve the microwave user inter­face, shift­ing away from four char­ac­ter sev­en seg­ment dis­plays to a more inter­ac­tive ful­ly fea­tured dis­play.

Every­thing 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­al­ly look like.

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

Then I did a pro­to­type imple­men­ta­tion in HTML to iter­ate the bet­ter ideas. This pro­to­type is below, it is a ful­ly inter­ac­tive web­page — some bits pre­tend to work, oth­er bits are stubbed out.

I would real­ly appre­ci­ate it if peo­ple would play and give feed­back. It is designed for a fixed screen size of 480x800 pix­els, the pri­ma­ry user inter­face will be fin­ger on a touch­screen, there will also be gen­er­al web brows­er access for PCs and portable devices.

View in new tab/window

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

My cur­rent design guide­lines are:
  • Intu­itive to use
    • No instruc­tion man­u­al or help pages
    • No advanced touch inter­faces (slid­ing, mul­ti­touch etc.)
    • Large, obvi­ous, touch tar­gets
    • Acces­si­ble colour scheme and aria sup­port
  • For­giv­ing of mis­takes
  • Not too hideous­ly ugly
Return top