Console application for MTAPI

No, this is still not the power measurement post.  Richard will get around to it soon, honest.

We spend a lot of time playing around with TI's CC2538 Zigbee chip running Z-Stack, which means that we spend a lot of time programming other embedded chips to talk TI's Monitor and Test API serial protocol to it.  Needless to say, debugging at more than one CPU's remove can be a tedious exercise, and there's nothing (that I know about, at least) that will allow you to talk MTAPI to a CC2538 from your nice, comfortable Linux development environment.

Enter MTConsole, in the http://github.com/kynesim/MTConsole repository.  In a fit of enthusiasm, and a strong desire to be able to script tests, I've put together a Python program to translate to and from MTAPI.  It is limited at the moment, and some areas are, to be blunt, not very pretty.  It falls over with an exception on a parse error, for example, because that was what I wanted when testing the parser.  That will get visited with fire and the sword when it first annoys me in real use.

So far I've put a lot of effort into parsing binary input (from the CC2538) into text, and not much into parsing text into MTAPI commands.  That will be changing as I need more commands (fire and the sword, people), but at the moment it's not useful for much more than proving that your chip is up and talking to the outside world.  Useful as that is, I would eventually like to get to the point where I can script it well enough to mock up complex command sequences.

Please feel free to grab and use as the mood takes you.  Patches, bug reports, comments and suggestions are always welcome, just bring your own sword.

Hacking Wireshark for fun and profit

We've been working on some low-power Zigbee sensors recently, based on CC2538 / ZStack 1.2.2 and running Zigbee HA 1.2.1 ; whilst we were doing this it occurred to us that Wireshark could usefully decode a few more of the IAS Zigbee messages into something useful.

So we did that.

It also turns out that some of our clients (and compliance test houses) use the very nice Ubiqua protocol analyser tool

However, we are a Wireshark shop.

Step up Vadim , who contributed a bunch of patches in Wireshark bug 7426. Those had rotted a bit, so I resurrected them and the upshot is that the http://github.com/kynesim/wireshark repository now contains a bunch of things that Zigbee hackers might find fun:

• Better decoding for Zigbee IAS messages - from Rhodri James.
• Support for CUBX, TI SmartRF Studio and Ember Insight Desktop file formats as per Vadim's patch.
• Support for more recent Ubiqua 3 file formats (at least, on the traces I have here).
• A nasty backdoor mechanism so that you can decode Ubiqua traces which don't contain the TC key transport packet in the trace (Ubiqua stashes this in a separate table, and we pass it round the back to the Zigbee packet dissector).

One day I will get around to trying to push this lot upstream, but I suspect we will want a better way to do the backdoor key transport than the ugly hack I have in there at the moment.

Anyway, if you feel minded, grab it, enjoy and do report any bugs you come across (and I will do another post on power measurement for low-power radio, honest).

It's been a while ..

It looks as though the last post on this blog was waaay back in 2013, which goes to show how busy we've been. So, what's happened between then and now? Well, our open source stuff has migrated to github - https://github.com/kynesim . There you'll find a bunch of stuff you might find useful, including:

• The venerable tstools and muddle.
• Our local variants of ccsniffpiper - a program which allows you to sniff Zigbee with a TI CC2531 USB dongle, and wireshark - which contains some patches from Rhodri that help decode Zigbee HA IAS ACE commands in a more friendly way.
• The current version of kbus - still 10% the size of kdbus :-)
• upc2 - an easy to use, easy to cross-compile, terminal program that can speak xmodem and Andrew Gordon's semi-proprietory grouch protocol.

And lately we've been playing with some automotive powertrain stuff, some very low power Zigbee sensors based on TI ZStack Home 1.2.2a (under some circumstances, you can get battery life projections as long as the shelf life of the batteries), BT LE dynamic advertising with Android, and TI's newer, even lower power CC2650 - but those will have to be the subject of their own posts.

Changing the "theme" in Enthought Traits UI with Qt as the backend

I'm currently writing code for a customer using Enthought Traits, and in particular Traits UI. Traits as a whole is a very nice toolkit for use in scientific programming, but you can find out about that by googling in the normal manner.

The specific issue, though, is  that we've moved to using pyside/Qt4 as the GUI backend, instead of wx(Python) - enabled, for instance, by doing:

    try:
        from traits.etsconfig.api import ETSConfig
        ETSConfig.toolkit = 'qt4'
    except ValueError:
        pass

Some things are done a little bit differently with the Qt backend, though, and it's not always obvious how. In particular, traits UI has always allowed "theming", and the normal way to do this with the traditional wx backend is using something like:

    from traitsui.api import Theme
    ...
    Item('move_to_loading_area_btn', item_theme=Theme('@std:BE5')),

 (note that this is not the syntax for the item_theme argument shown in the documentation, that doesn't seem to work - so this is also "a useful reference").

This doesn't work with the Qt backend. It turns out that the way to do it is to specify a Qt stylesheet, which can be done as a string:

    Item('move_to_loading_area_btn', style_sheet='* { color: red }'),

Useful Qt references are then:

• http://qt-project.org/doc/qt-4.8/stylesheet-syntax.html
• http://qt-project.org/doc/qt-4.8/stylesheet-reference.html#list-of-properties
• http://qt-project.org/doc/qt-4.8/stylesheet-examples.html

(blogged here because no-one else seems to have described doing this)

A report on PyConUK 2013

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.

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

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.