As usual, this was a very enjoyable conference. I had fun, I met lots of
interesting people, and I learnt things.
This is mostly a report on the program, because that's the easiest thing to
write about, and because some of these notes are for work.
Sunday, 29 September 2013
Monday, 26 August 2013
Ambient backscatter radio
It seems that some folk at U. Washington have managed to implement an idea that I've been playing around with for a while - ambient backscatter. Now what we need are far, far better reflectors - their system only really works well at distances of 2-3 feet in free air, and really what we need is something that can get through walls.
On the other hand, if their aerials can be made smaller, they could reflect WiFi signals, which have much higher local intensities than distant TV transmitters and whose reflection characteristics are fairly well known thanks to all the folk doing diversity with them.
I wonder if a semi-intelligent aerial which spots beacon frames in h/w is a good thing to have - on the one hand, it provides a known timing reference for the receiver to try and wake up to, but on the other you will have all of the distance-related wakeup window issues.
The other thing one can do over the UW study in a home hub environment is, of course, to have a pulsed interrogation transmitter - notably if you operate in 868MHz or 2.4GHz that transmitter can be on the same frequency as your ambient radio, so you can work in a wait_for_reflect-pulse-wait_for_result mode, which allows you to get quite high power intensities without interfering too much with WiFi (particularly if you are listening to the WiFi and know when its slots are).
This (in some form) is obviously the right technology for things like window sensors - now you only need to change batteries in one room, not one every sensor.
Anyway, have a link - it's an interesting read: http://abc.cs.washington.edu/files/comm153-liu.pdf
On the other hand, if their aerials can be made smaller, they could reflect WiFi signals, which have much higher local intensities than distant TV transmitters and whose reflection characteristics are fairly well known thanks to all the folk doing diversity with them.
I wonder if a semi-intelligent aerial which spots beacon frames in h/w is a good thing to have - on the one hand, it provides a known timing reference for the receiver to try and wake up to, but on the other you will have all of the distance-related wakeup window issues.
The other thing one can do over the UW study in a home hub environment is, of course, to have a pulsed interrogation transmitter - notably if you operate in 868MHz or 2.4GHz that transmitter can be on the same frequency as your ambient radio, so you can work in a wait_for_reflect-pulse-wait_for_result mode, which allows you to get quite high power intensities without interfering too much with WiFi (particularly if you are listening to the WiFi and know when its slots are).
This (in some form) is obviously the right technology for things like window sensors - now you only need to change batteries in one room, not one every sensor.
Anyway, have a link - it's an interesting read: http://abc.cs.washington.edu/files/comm153-liu.pdf
Thursday, 14 March 2013
Muddle v2.5.1 - change in how "muddle pull" works
If "muddle pull" is given a command line that includes the build description (implicitly or explicitly), it will pull the build description first, and if that pull changed things, will reload the build description and re-evaluate the command line, before pulling the other checkouts requested.
This means that you no longer need to check if "muddle pull" changed the build description and then do it again if it did.
See "muddle help pull" for a more complete description.
If you do want the old behaviour, use "muddle pull -noreload".
As a consequence of this change, the "_just_pulled" value is now set by "muddle checkout" as well as by "muddle pull".
This resolves issue 218.
Wednesday, 13 February 2013
Muddle v2.5 released
Upgrade to the latest version of muddle in the normal manner:
$ cd
$ git pull
I believe that it all works, but if you have problems with v2.5 (which has had some substantial code rewrites in various areas), consider reverting to Just-before-2.5, which was the last checkin on the old "master" branch::
$ cd
$ git checkout Just-before-2.5
Changes in v2.5 since v2.4.4 are listed after the break:
Monday, 28 January 2013
muddle - CPIO support in packages
There is a new version of muddle, which addresses issue 201: Allow CPIO file creation by a package, not just by a deployment, and also has some internal amendments which should not be visible.
Thursday, 3 January 2013
muddle - "no invocation"
Muddle is updated, but you shouldn't be able to tell the difference...
This update is tagged "no-invocation", and is mostly an internal technical change.
Short description: wherever you have written "builder.invocation." you can now write "builder.", leading to shorter lines in your build description, which is a Good Thing. However, "builder.invocation." will continue to work.
Long description: after the cut.
This update is tagged "no-invocation", and is mostly an internal technical change.
Short description: wherever you have written "builder.invocation." you can now write "builder.", leading to shorter lines in your build description, which is a Good Thing. However, "builder.invocation." will continue to work.
Long description: after the cut.
Monday, 17 December 2012
New muddle "quickstart"
The muddle documentation has now gained a "Quick start" section, at http://muddle.readthedocs.org/en/latest/quickstart.html. I've also added an introduction, which more-or-less matches the front page text on Google Code.
Subscribe to:
Posts (Atom)