Smart meters

By: on March 31, 2015

I’ve been using a micro-controller to automatically dim lights according to the time of day and ambient light conditions. At some point, I decided it would be easier to tinker with if I just used a raspberry pi, logged into it, and edited a python program.

This doesn’t work: The pi basically can’t do PWM – when you change the value, the light visibly flickers. It’s not an easy thing to do without dedicated timer hardware.

Back then to a little micro-controller eval board, then…

What if I can have it both ways? All but the most primitive REPL is going to be a bit heavy for devices that typically have 10s of Ks or RAM, but a remote REPL that injected code into a byte code interpreter could be feasible.

I haven’t found anything quite like this, but a great starting point is Picobit scheme. I’ve got it running on one of these. You can see my port here. I’m busy adding remote debugging support. At the moment I’ve only got as far as getting the compiler to emit a source code map for the byte code.

Another thread of investigation I’m following is porting Bletchley to Scheme. I’m interested in that because it’s easy: Bletchley is S-Exp based, and I could embed a small scheme interpreter like Tiny Scheme or Chibi Scheme to make Bletchley available in a C based environment.

This sounds like an article about evaluating Scheme interpreters, So why the title?

Bletchley is a very good basis for secure communication in this context: It’s flexible key management could be used to limit the authority of any one actor in the system. Master keys need never get any where near the internet, but time limited keys could always be issued in emergencies, to expedite recovery, for example.

It seems reasonable to assume a version of Bletchley can run in Picobit.

S3 is a tiny TCP/IP stack implemented in Scheme, that already runs in Picobit, so that’s the rest of the communication infrastructure covered.

Running communication code in the safe environment provided by a virtual machine is a great way to keep smart meters secure, and Picobit is small enough to be almost un-noticeable in terms of hardware cost.

S3 is a tiny TCP/IP stack implemented in Scheme, that already runs in Picobit, so a lot of the infrastructure is already present.

In addition, Picobit’s VM is tiny. Formal verification techniques could quite easily be used as a means of QA.

Share

2 Comments

  1. Derrick Anderson says:

    I just want to point out that Pulse Width Modulation is perfectly achievable on the PI, the only issue is the Clock interrupting on a high level script. Any PWM needs to be done on a daemon level to avoid getting interrupted every cycle.

    😀

    I ran into this issue using servo’s on my personal project.

  2. David Ireland says:

    A daemon in Unix is simply a process not connected to a terminal. It can certainly still be interrupted (as can any Unix process). You can reduce the risk of being interrupted by setting negative niceness. Perhaps that’s what you mean? I’m assuming in your project you are using bit banging: that is, you manually turn the output on and off, or this would be relevant anyway. I’m using a library that in turn uses a DMA loop. This actually can’t be interrupted, and works perfectly while you don’t change the value, but when it re-writes the buffer, it doesn’t take into where the DMA is up to, which creates a glitch. It’s pretty clearly visible in the light output. Perhaps this glitch is worse than the inaccuracies of bit banging at low frequencies (servos run at 50Hz) but safe motor pwm is generally 10Khz, and bit banging really won’t be accurate enough.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*