To the right is a picture of the motherboard of one of my Macintosh Plusses upgraded to a 68010 microprocessor. After the 68030 powered Macintosh SE/30, I think Macintosh Plus/10 is an appropriate name.

The 68010 does not bring much improvement, multiply/ divide is supposed to be somewhat faster.

The cpu upgrade is interesting, but Plus/10 is mostly meant as a start to do some hardware experiments with this classic Macintosh.

The bottom side of the upgrade board with plenty of empty space for more hardware is pictured below.

More to follow…

Before my boards arrived, I had already made the central heating temperature logger and forgot about them. Today I soldered one of these boards as a test, the result is in the picture to the right. The board is mounted on a simple breakout that I made for my ESP8266 experiments. The sensor itself is not visible, as it is on the bottom side of the black PCB, so that it can easily be mounted to a surface and make proper thermal contact.

Compared to the DS1820 one-wire sensors, the temperature resolution is not that great, only 0.5 °C resolution, but interfacing these is a lot easier. To make interfacing even easier, I created a small Lua library to read an LM75 sensor from NodeMCU, it’s available in the public domain on Github.

Usage is easy:

1
2
3
4
5

require('lm75')

-- GPIO indexes of i2c signals
sda, scl = 4, 3
lm75:init(sda, scl)

The temperatures can then be read as either a sting repreenting a floating point value or scaled to an integer (temperature in °C is value/10.)

For example:

1
2
3
4

> =lm75:strTemp()
22.5
> =lm75:intTemp()
225

Using this library, a sensor node that emits temperatures in mrtg external script format to a TCP client can fit in this tiny snippet of code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

require('lm75')

sda, scl = 4, 3
port = 27315

lm75:init(sda, scl)

srv=net.createServer(net.TCP)
srv:listen(port,
        function(conn)
                local temp
                temp = lm75:intTemp()
                conn:send(
                        temp.."\n"
                        ..temp.."\n"
                        ..tmr.now().." ticks\n"
                        .."node-"..node.chipid())
                conn:on("sent",
                        function(conn) conn:close() end
                )
        end
)

See my previous post about how to easily integrate this into mrtg using netcat.

Enjoy!

I had some more fun with Lua on the ESP8266 wifi modules. These things are so cheap and so versatile that I have already reserved a dedicated subnet for sensor nodes in the house.

The latest ESP8266 projects are a temperature logger for the water temperature of the central heating and a meter reader for water consumption.

The NodeMCU Lua firmware has native support for onewire, making it trivial to add some DS18B20 temperature sensors. A bit of Lua glues these to a TCP socket and outputs the sensor values when a TCP connection is made. This way it is very easy to grab the sensor values from MRTG.

MRTG Then generates pretty graphs like the one below. In this graph the red line shows the hot water from the central heating boiler, the blue area is the return water temperature.

The code behind this is too dirty to publish, some cleaning up needs to be done first. The water usage logger is a better example.

The water usage logger uses a reflective infrared sensor mounted on the water meter. The water meter has a disc with a reflective part that the sensor can detect, giving an impulse per liter of water used.

The impulse output of the sensor is connected to a GPIO on the ESP8266, the ESP8266 increments a global counter on every impulse received. It also listens for TCP connections, when a connection is received it emits the measured values in the format that MRTG expects for external scripts. Thus making it easy to gather the values from MRTG using nothing more than netcat.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

gpio0 = 3
gpio2 = 4

count = {0, 0}

gpio.mode(gpio0, gpio.INT)
gpio.mode(gpio2, gpio.INT)

function increment(index, state)
  count[index] = count[index] + 1
end

gpio.trig(gpio0, "up", function (state) increment(1, state) end)
gpio.trig(gpio2, "up", function (state) increment(2, state) end)

srv=net.createServer(net.TCP)
srv:listen(5555, function(c)
        str = ""
        for i=1,2 do
                str = str .. tostring(count[i]).."\n"
        end
        str = str .. tostring(tmr.now()).." ticks\n"
        str = str .. "node-"..tostring(node.chipid()).."\n"
        c:send(str)
        c:on("sent", function(c) c:close() end)
end)

On a TCP connect the ESP8266 emits something similar to this:

402
0
1915768749 ticks
node-12341234

This is exactly the format that MRTG uses, making MRTG side of things very simple:

1
2
3
4
5
6
7
8
9
10
11
12

Title[water]: Water Flow
Target[water]: `/bin/nc water.metering.iot.intra.isquared.nl 5555`
PageTop[water]: <H1>Water Flow</H1>
Options[water]: nopercent, noo, perminute
MaxBytes[water]: 10000
Factor[water]: 1
YTicsFactor[water]: 1
WithPeak[water]: wmy
YLegend[water]: Liter/min
ShortLegend[water]: l/min
LegendI[water]: flow
Colours[water]: BLUE#2222aa, BLUE#2222aa, LIGHTBLUE#3399ff, LIGHTBLUE#3399ff

The gas and electricity meters still pose a bit of a problem, the infrared sensors have a had time picking up a signal from those. For electricity

I’ll probably add one or two kWh meters with an S0 output behind the meter provided by the utility company. This is easier and probably more reliable than trying to read the meter optically.

Graphing many more values using MRTG will probably also demand too much from the Raspberry Pi that now does all the graphing. A cusom solution using RRDTool will probably be a better solution.

Development for these modules has recently gotten even better with the release of Lua firmware for these modules. Not that I’m particularly fond of Lua as a language, but it is lightweight and its not too hard to whip up some code in it without much experience. And that is what I’ve been doing today, I wrote some Lua code that runs unattended op the module, scanning for nearby wifi access points and sending these, along with the signal strength (RSSI) value to a server in my home network.

I hope to build a rudimentary location based service with this, tracking the location of the ESP8266 module through the house.

The code for the location tag is pretty straightforward:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

wifi.setmode(wifi.STATION)
wifi.sta.config("essid", "wpakey")

function listap(t)
        myid = string.lower(string.gsub(wifi.sta.getmac(), "-", ":"))
        conn=net.createConnection(net.UDP, false)
        conn:connect(8021, "192.168.1.1")
        conn:send(myid..": begin scan\n")
        for key,value in pairs(t) do
                enc, rssi, bssid, chan = string.match(value,
                        "(%d),(-?%d+),(%x%x:%x%x:%x%x:%x%x:%x%x:%x%x),(%d+)")
                conn:send(myid..": "..bssid..","..rssi.."\n")
        end
        conn:close()
end
tmr.alarm(0, 30000, 1, function() wifi.sta.getap(listap) end)

Every 30 seconds the tmr.alarm() call fires wifi.sta.getap(). This function scans for wifi networks and makes a callback to listap() on completion of the scan. The listap() function munges the data from wifi.sta.getap() and pushes it through some UDP packets to a remote host for further processing.

Right now on the remote host there is just a netcat listening:

hessch@leibniz ~ $ nc -ul 8021
18:fe:34:yy:yy:yy: begin scan
18:fe:34:yy:yy:yy: 84:9c:a6:xx:xx:xx,-76
18:fe:34:yy:yy:yy: 00:20:91:xx:xx:xx,-47
18:fe:34:yy:yy:yy: d4:ca:6d:xx:xx:xx,-46
18:fe:34:yy:yy:yy: d8:bx:4c:xx:xx:xx,-85
18:fe:34:yy:yy:yy: begin scan
18:fe:34:yy:yy:yy: 84:9c:a6:xx:xx:xx,-74
18:fe:34:yy:yy:yy: 00:20:91:xx:xx:xx,-49
18:fe:34:yy:yy:yy: d4:ca:6d:xx:xx:xx,-48
18:fe:34:yy:yy:yy: d8:bx:4c:xx:xx:xx,-85

Eventually a script should be listening here that computes a likely position based on these values. Not sure yet how I’m hoing to implement this, maybe more about this in a later post.

Playing with Lua on the ESP8266 today, though, makes me believe that its not very likely that I’ll come anything near to an Arduino for anything wifi related.
The combination of a interpreted language like Lua and Wifi for this price is unbeatable, the only things that I’d really like to see still are IPv6 support and access to raw wifi packets, preferably in monitor mode.

I’m already planning a few more projects with these modules: a physical switch for my Lifx lightbulbs in the house and various sensors for energy measuring.

The ds89c21 chips fit the board designed in the previous post and led to some first tests with a rs-422 differential link. First of all, I found that I had omitted the bias resistors necessary for the rs-422 link on the link input in my design. These were easily bodged to the board for a quick test, the ugly results of impatient soldering shown to the right. But no success, the link input remained pinned to a logic high signal.

A few days of debugging later, it suddenly dawned to me to cross the wires of the link and the link immediately sprang to life. Doh. For now the link seems to be reliable even at 20 Mbit/s, great.

I rechecked the schematic and the board silkscreen, seems that even though the ds89c21 seems to match the board, these plus/minus lines on either the receive or transmit lines are swapped in respect to the board layout.

The oscilloscope picture to the right shows that the negative signal has some nasty degradation, while the positive is pretty decent, strange. It may just as well be the terrible bodged-on bias resistors, but I can’t really explain why this would affect only one of the signal lines.

Oh well, time for more interesting tests than a simple loopback.

This time I managed to bring up the patience to do some quick tests on a breadboard before committing it straight to a PCB. The tests on breadboard looked promising, although I used a C012 link adaptor chip for the breadboard tests instead of the C011 used in the PCB version.

This new version is based on the Microchip MCP23017 16-bit i²c GPIO interface instead of the two PCF8574’s in the previous version.

Using only one chip makes the software side a bit easier, but the main reason I chose the MCP23017 over the PCF8574 was that I did not really trust the quasi-bidirectional IO of the latter in my previous design. The MCP23017 feels more deterministic in that respect, giving the user control over each GPIO’s direction, its default value, etc. A pretty nice chip.

All IO is now running on 5 volt, as the i²c bus is active low and pulled up to 3.3 volt by the Raspberry Pi, the MCP23017 can safely run on 5 volt without damaging the Raspberry Pi’s GPIOs.

The Inmos link, a reset line and a 5 MHz clock are available as buffered TTL signals, the link speed is selectable in software, of course with the obligatory associated blinkenlights. The IMS-C011 InputInterrupt and OutputInterrupt signals are OR-ed trough to open-collector outputs to one of the Raspberry’s GPIO’s.

I planned these signals to be available through rs-422 line drivers as well. The rs-422 transceivers I picked from Eagle’s component library seem to be either made from unobtainium or from unaffordium, though. These need to be replace with something more commonly available. As the board outline interferes with the Raspberry Pi’s ugly USB connectors as well, a third version of the board may hopefully straighten out these last few glitches.

But…does it work this time? Well, yes, it seems so, although more testing still needs to be done.

To the right is the new link interface in all its glory booting a lowly T222 Transputer.

The Raspberry’s side of things is using a little Python module to abstract the MCP23017 and C011 link adaptor from programs.

With default i²c addresses and a 10 Mbit/s link, writing a byte to the link is a simple as:

import Inmos2
link = Inmos2.Link()
link.write(0x42)

The T222 booting using the new link adaptor is shown below:

hessch@archimedes ~/src/rpilink $ ./tdetect.py
Writing 23 bytes of boot code to Transputer:

    b1 d1 24 f2 21 fc 24 f2 
    21 f8 f0 60 5c 2a 2a 2a 
    4a ff 21 2f ff 02 00 

Read result from Transputer:

    aa aa


16-bit Transputer found

It’s alive!

The Maintenance Test Panel is located in the cockpit of the aircraft, behind the first officer. It stores fault information from all computers that make up the automated flight system and can run tests initiated by maintenance engineers. In essence it is the debug port, or for car people, the OBD-II port of the airplanes computers.

I have close to no documentation about this unit, or its use, but it is a fun toy to play with, built with price being no issue. It is a self-contained computer system around an Intel 8085 microprocessor, a couple of Harris, now Intersil, HS-3282 ARINC-429 interfaces for communication and a two-line liquid crystal display (LCD), that is very low in contrast and lit by two good old incandescent light bulbs.

The LCD is interesting as it has no built-in character ROM, something that is rare for character LCD modules, at least nowadays where most LCD’s use a Hitachi HD44780 (or compatible) controller.

The character set for the display is stored in an EPROM on the first printed circuit board module in the unit. In the process of reverse-engineering the MTP, I made a dump of this EPROM, an Intel 2716 from the 20th week of 1981.
Why do I care so much about this date, you probaby ask?
Well, I extracted the character definitions from the ROM dump and was amazed by the amount of bitrot. Dozens of bits had clearly lost their value in this ROM. Which made for an interesting hour or so in a hex-editor, fixing the glyph definitions in the ROM dump.

After that, I tried to write the fixed ROM dump back to an EPROM. Not wanting to erase the original EPROM in the unit, I rummaged through my junk drawers and found a couple of old Soviet КР537РФ2 ROM’s. These chips should be 2716 compatibles, which was good news. Just to find that my, otherwise pretty good, TL866 programmer was not able to supply either the voltage or the current necessary to program these chips.

Already in the later hours of the evening I dug out an EPROM programmer of a vintage closer to the EPROMs to be programmed. I had bought the programmer already some years ago, but never took the time to try it. The great thing of this programmer is that it has a serial command based interface. No software on the host pc is really necessary, if you are willing to compile many arcane hex-values from bit-fields defined in the documentation and type these into a terminal, what is exactly what I did.
This is also how I had to do it, as the (although still available) software is written for long gone versions of MS Windows and I mostly use Mac OS and various other Unix flavors for my hobbies. A Windows XP virtual machine that I keep for moments like this, was certainly too recent for the programmers software, already.

Hours of fumbling with conversion to Motorola S-record formats that the programmer requires and serial line voodoo later, (my EPROM eraser running overtime in the process too) I managed to burn the fixed ROM image to the replacement EPROM chip.
If you can make out the faint text in the display in the first picture of this article, the result is just about visible.

Useful? No, certainly not, as I don’t own an Airbus A300. ;) But it made for some fun adventures with obsolete electronics, again.

The MC68000 in the Macintosh Classic is a surface mounted 68-pin PLCC package, of course it’s possible to attach many SMD grabbers to the pins of this package, but that is far from practical.

True PLCC test adapters are far too expensive for hobbyist purposes, so I tried something else, with good results. On Ebay, I ordered a few PLCC86 sockets, and tried to placed one on top of the MC68000. This works, but not reliably, as the contact springs of the socket force the socket off the IC package.
By sanding down the PLCC socket and removing four internal notches, the socket can be pushed farther over the IC and you get a pretty snug fit.

Spot the differences in the pictures below, left the original socket, right the modified one.

The modified socket attaches tightly around the PLCC IC to be probed, tight enough that it takes some force to remove it again. Certainly good enough for probing, but it may even suffice for adding hardware permanently to the machine.

Below you can see the socket mounted on top of the MC68000 on a Macintosh Classic logic board.

Once mounted on the board, it’s easy to attach logic analyzer pods to the socket pins. But as you can see in the last picture, this becomes a ratsnest pretty fast. It suffices for now, but terminating the logic analyzer to an adapter PCB with proper header connectors for this purpose will be the next step.

The Raspberry Pi link interface uses two PCF8574 I2C I/O expanders to interface to the Raspberry Pi. I2C makes development easier, as all can be done in user-mode using Python.

The software that I wrote for the AVM M1 before was not reliable, first I thought this was due to my own programming, but on more investigation it turs out that the AVM driver is interfering, but without a driver the Linux PCMCIA subsystem doesn’t allocate resources for the card.

For my purpose and because I was getting on a roll designing some other printed circuit boards in Eagle, I deciced to postpone the M1 for a while to experiment with this new link board for the Raspberry Pi.

The PCF8574 I/O expanders divide the work, one (on i2c address 0x20) handles the databus to the IMS-C011 link adapter, the other (on address 0x21) the control signals.

The circuit board shown above still has some issues, it could use a better shape to clear the composite video connector on the Raspberry Pi. I had wired the Input and Output interrupts of the IMS-C001 directly to some Raspberry GPIO’s without thinking of the 5 volt levels the IMS-C011 uses, to prevent damage to the Raspberry Pi’s GPIO’s I’ve cut the races to these GPIO’s on this board.

No software has been written yet, but the first hardware tests seem to be ok, the 5 MHz oscillator is running and both PCF8574’s can be seen from the Raspberry Pi side of things:

hessch@leibniz ~ $ sudo i2cdetect -y -a 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

The status LED’s can be made to blink with a quick and dirty shell script:

1
2
3
4
5

while [ == ]
do 
  sudo i2cset -y 0 0x21 0x40 0xff; sleep 1
  sudo i2cset -y 0 0x21 0x40 0x00; sleep 1
done

So far so good, to be continued…

Since IBM compatible PC’s are almost the complete opposite of Transputers in interestingness, I didn’t really like to invest scarce space in my house for a boring grey PC box just to fit the B004 cards. I had already been toying with the idea of making a custom interface from ISA to something more modern, but luckily I found a better option:

Axel Muhr describes on this page (geekdot.com) onwards his hacks using AVM B1 active ISDN controllers as B004 sustitutes. There is a PCI version of the B1, but I wasn’t sure about compatibility and the price of these cards is still higher than what I paid for my original B004’s.

Enter the AVM M1 PCMCIA card…

This card seems to be a PCMCIA variant of the B1 hardware, has 1 MB of RAM and a IMST400 Transputer on board. Making Transputers compatible with reasonably modern laptops! Oh, and these cards can be had for a few Euro a piece on Ebay.

I did some quick reverse engineering of this card. The link adapter is implemented in a Xilinx XC3164A FPGA and the T400 seems to boot from link 0. The link adapter in the FPGA looks to be IMSC012 compatible. The config of the FPGA is fixed and stored in a serial configuration ROM. Then there is a parallel EEPROM that holds all PCMCIA parameter info and a second serial EEPROM, presumably for settings storage.

The M1 was meant to interface with Siemens GSM mobile phones and as such has no ISDN controller inside, just an UART. In our case, this is actually good news, as there is no other crap attached to our precious Transputer. A similar card, called M2, exists and has exactly the same hardware but also a Siemens ISDN chipset fitted on the board.

The UART can easily be removed from the PCB, and there is probably enough space to fit some buffers or even a RS-422 driver to feed the remaining free link (link 1) to the outside, as I plan to do when I get the software side up to scratch. From there on it would be easy to bootstrap larger Transputer networks from this PCMCIA card.

A quick test with the original CAPI drivers for Linux confirms that this card appears to the host just like a B1 (and so like a B004!):

hessch@bt:~$ dmesg
...
[ 9888.081914] b1pcmcia: AVM M1 at i/o 0x150, irq 3, revision 3
...

The only problem, as could be expected with ancient hardware, is that all Linux Transputer link drivers that I could find are equally ancient. Ancient and crufty.

As a quick test, I modified Apple II interface code, also from Axel Muhr’s geekdot.com. I translated this to a bit of Python code that uses portio to do I/O with the M1 to test loading code to the T400 Transputer. My code is far from reliable, in its current state. Actually it seems more like it worked by accident, shown here:

hessch@bt:~$ sudo ./tdetect.py 
ioperm() was successful for all C012 registers from 0x150 onwards

resetting Transputer...

ISR value: 0x0
OSR value: 0x1

writing data to Transputer:

    17 b1 d1 24 f2 21 fc 24 f2 21 f8 f0 60 5c 2a 2a 
    2a 4a ff 21 2f ff 2 0 

read result from Transputer:

    aa aa 0 0 

Yay, we have a 32-bit Transputer answering!

I’m not really bothered by the reliability of my code yet, as it would be still a lot of work to make this in something useful. Having the common Transputer link infrastructure in place should make all old userspace stuff that is still available come alive again. Probably, I will strip all CAPI/ ISDN related stuff out of the working AVM M1 driver that is in the current Linux source tree and implement Transputer link driver compatible ioctl’s in that driver, as all needed functionality is already in the existing M1 driver in Linux. While writing the Python code mentioned above I had a good few reads of the source of this module already and it is quite readable, which gives me better hopes of getting something working than trying to bring the old Linux link drivers back to the 21st century.

I’ll probably create a new page somewhere on this site to document my progress. When that happens, it will be linked from here.

There exist a few online hexdump tools already, but these all require you to upload a file to a remote server, which may be inappropriate. Also, in most cases these tools produce an output quite unlike what we are used to with od, xxd and the like. I wanted something closer to what my favorite shell utilities produce.

My (still experimental) tool processes files locally in JavaScript, using HTML5 local file access and produces something similar to hexdump -C’s output, without byte grouping.

A screenshot of the tool in action is shown below:

This tool may be useful in circumstances where you don’t have a machine with a proper operating system at hand and quickly want to inspect some file.

It still has some rough edges and especially large files may hang the browser. I learned the rough way that document.createTextNode() is very expensive, and had to replace many instances of it with simple string concatenation and a single call to createTextNode(). That speeded things up a lot.

The most interesting part of the code is the formatting of the hex dump output, this is shown below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

for (var i = 0; i < this.image.length; i++) {
  // write address
  if (i % 16 == 0) {
      var a = i.toString(16);
      while (a.length < 4) a = "0" + a; // FIXME: hardcoded format 
      frag += a + ": ";
  };

  var c = this.image[i];       // raw byte (char)
  var cc = c.charCodeAt(0);   // charcode

  // format byte
  var h = cc.toString(16);
  while (h.length < 2) h = "0" + h;
  frag += h;

  // append char to ascii representation, print non-printable as "."
  ascii += (cc > 31 && cc < 127)?c:'.';

  // format columns
  frag += (i % 16 == 15)?ascii + "\n":" ";

  if (i % 16 == 15) ascii = "    "; // clear ascii rep. on newline
};

// handle last line, pad empty bytes
for (var s = 0; s < (16 - (i % 16)) * 3 - 1; s++) frag += " ";
frag += ascii + "\n";

// commit fragment to DOM
this.appendChild(document.createTextNode(frag));

This code was originally written for another purpose and it does not format addresses over 0xffff properly, but I will fix that sooner or later.

More output format options (byte grouping, columns, etc.) would also be useful, but implementing that requires some cleaning up of the code above, as it is already turning crufty after a few iterations. :)

This board is part of an experiment with cellular automata that I’m sometimes spending my thoughts on. Like almost all the stuff I do, this project as to compete for my attention with many other unfinished stuff.

The board will be populated with 16 Atmel ATTiny13 microcontroller, of which I had already ordered a lot of 50 pieces from Ebay.

All components will hot air soldered using stencilled on solder paste.

This weekend I experimented with programming the SO-8 packaged microcontrollers. To do so I also ordered a programming adapter from WaveShare as pictured below.

This adapter allows programming of the comtroller before soldering it to the board. I’ll probably prototype on breadboard anyway. I want to be able to dynamically load code to the controllers which will be executed in a simple virtual machine.

To test code running on the Tiny13, I’ve made a small plug with 3 LEDs that can be attached to one of the headers of the programming adapter. The LEDs show the state of PB0 - PB2, actually the inverse state, as the GPIOs sink Vcc in this case.

It didn’t take long to get the first code running on the Tiny13, blinky LEDs this weekend!

Time to think of implementing a protocol for the controllers to exchange state information, updating code on a remote controller as well as synchronizing the controllers as they will all run asynchronously by default.

Since I’m lazy, I’ve updated source/_includes/head.html to fall back to using categories as keywords for a page if no keywords are given.

As this may be useful to other Octopress users, this is what I’ve changed: In source/_includes/head.html, change:

1

{% if page.keywords %}<meta name="keywords" content="{{ page.keywords }}">{% endif %}

to:

1
2
3
4
5
6
7
8

{% capture keywords %}{% if page.keywords %}
  {{ page.keywords }}
{% elsif page.categories %}
  {{ page.categories | join: ', ' }}
{% else %}
  {{ site.keywords }}
{% endif %}{% endcapture %}
<meta name="keywords" content="{{ keywords }}">

and Octopress will default to the categories of a post to use as meta keywords.

Well, somewhere this year I revisited that project and wrote a set of Psion OPL programs to create and manipulate a small framebuffer implemented in eight characters of the Psion’s little LCD. Actually, since I’m nowadays the proud owner of a Psion Organiser II model LZ64 , the LCD is larger than it was in 2009. ;)

The library of OPL programs is called UDGFB and is available on Github. Should I ever update it, expect it to appear there.

More technical details about UDGFB after the break…

The framebuffer uses the user-defined characters printed in the following configuration:

1
2

udg0 udg1 udg2 udg3
udg4 udg5 udg6 udg7

The following functions are defined:

• clearfb:

  clears the framebuffer

• printfb:(xpos, ypos)

  print framebuffer UDGs at location (xpos, ypos)

• pset:(x, y, s)

  set pixel at (x, y) to state s, where “s” is 0 or 1

• pixel%:(x, y)

  get value of pixel at (x, y)

• blitup:

  scroll all pixels one row up, duplicates row 15

The following functions are for internal use:

• pokeudg:(char, row, value)

  write value to udg row of udg character

• peekudg%:(char, row)

  read byte defining row of udg character

An example of how to use UDGFB follows below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

fbtest:
  local x%, y%

  clearfb:
  printfb:(8, 2)

  at 3,1
  print "Framebuffer Test";

  y%  = 0
  while y% <= 15
    x% = 0
    while x% <= 19
      pset:(x%, y%, 1)
      x% = x% + 1
    endwh
    y% = y% + 1
  endwh

  while y% >= 0
    x% = 19
    while x% >= 0
      pset:(x%, y%, 0)
      x% = x% - 2
    endwh
    y% = y% - 2
  endwh

  at 8,4 : print "done";

The techniques used should be easily adaptable to all HD44780 based LCD modules. I may have a go trying this on an Arduino and a bare character LCD module. But first I’d like to port UDGFB, or at least the most frequently called functions, to machine code for the Organiser II.

More in about a year or four. In this pace, that is… :)

Our bedroom has this Squeezebox radio, that I mostly use as a clock and to play from Spotify.

The Squeezebox has an ambient light sensor that dims the screen when the lights go out. Which works fine, the screen is dim enough at night not to interfere with my sleep.

Anyways, of course I had enabled SSH access to the Squeezebox just after installing it. Last year I was poking around in its filesystem to discover the ambient light sensor hanging around in /sys:

1
2

$ cat /sys/bus/i2c/drivers/msp430/1-0010/ambient
345

Every variable in the hessch residence needs to be graphed, this data could not be left aside. Also, as the ambient light sensor faces the window in the bedroom, I thought this might give some interesting data on the length of the days.

I hadn’t played with Cosm before, and thought this was a good occasion to give it a try. (Cosm was called Patchube before, and is now renamed to Xively, probably as I write this they’re planning on another name.) It turned out Cosm was pretty easy to use, and I quickly whipped up a piece of shell script to send values from the Squeezebox to Cosm:

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/sh
APIKEY='MYAPIKEY'
HOST=insomnia.intra.isquared.nl
curl  --header "X-ApiKey: ${APIKEY}" \
  --request PUT \
  --data '{"datastreams":[{"id":"bedroom", "current_value":"'\
      $(ssh ${HOST} 'cat /sys/bus/i2c/drivers/msp430/1-0010/ambient' |\
          awk '{
             printf "%4.4f\n",(11.51293 - log($1 + 1))
         }' )'" \
     }], "version":"1.0.0"}' \
  --silent http://api.cosm.com/v2/feeds/83451

Actually this is a very ugly oneliner that I’ve cleaned up a bit, it’s still ugly code, though. It fetches the current sensor value over ssh from the Squeezebox, and spits it as JSON to Cosm. It also tries to munch the raw values a bit as the output of the sensor is far from linear.

The graph above is the last 3 month of data as displayed in Cosm / Xively / whatever, one can see the days already getting shorter and darker, going towards the inevitable winter.

Zooming to a days worth of data one can nicely see the sunrise around 5:00 UTC and the sunset around 18:00 UTC, and the lamp in the room switching on around 19:00 UTC:

It might be interesting to filter out the characteristic level of the lamps in the room as the lamps mess with measuring the length of the day. In the graph above the first peak in the graph (around 22:00 UTC) is the ceiling light, which is switched off and being replaced with a bedside lamp that has three dimmer levels, of which two can be seen in the graph. When I’m writing this, as you can see the ceiling lamp is switched on again. :)

It could be fun to analyze the data to get an insight in our sleeping patterns and maybe even if (and how) the daylight affects these.

Maybe to be coninued…

After trying a simple rule 110 cellular automaton as a first test for the display. I’ve now ported my Bash implementation of Craig Reynolds Boids to the MSP430 microcontroller.

A video follows after the break:

The bad compact camera video doesn’t really do justice to the effect, which looks a lot better and more fluidic in real life.

The code for this is written in the great Energia IDE, a fork of Arduino for the MSP430 Launchpad.

The code is pretty ugly, as this was a quick two hour hack on the couch last evening. Also like fi.sh, the Bash version, this doesn’t do real vector arithmetic, it just does calculations on the x- and y-components on vectors. Since C is more capable than Bash in this respect, I might update that later, although it isn’t really necessary to achieve the right behaviour.

The full code is included below, put on your peril sensitive sunglasses:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244

/* 
 * Boids for Olimex MSP430-LED boosterpack and Energia
 * mostly ported from fi.sh 
 * (http://isquared.nl/blog/2010/02/22/fi.sh-a-Boids-clone-in-Bash/)
 *
 * Hessel Schut, hessel@isquared.nl, 2013-04-07
 */

// The 8x8 led matrix
#define LATCH 6
#define CLOCK 7
#define DATA 14
#define DELAYTIME 1 // microseconds to wait after setting pin

// MIC seeds random()
#define AIN 0 // Note: AIN0 == pin2

// number of boids
#define NBOIDS 4

// minimum separation for avoid()
#define SEP 3

// frame buffer 
unsigned char image[8] = {
  0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00
};

// coordinates
typedef struct point {
  unsigned short x;
  unsigned short y;
};

// vectors
typedef struct vector {
  signed short x;
  signed short y;
};

// boids 
typedef struct boid  {
  point position;
  vector heading;
};

// boid instances
boid boids[NBOIDS] = {};

// clear framebuffer
void clearScreen() {
  for (int i = 0; i < 8; i++) image[i] = 0x00;
}

void setup()
{
  // set pin modes
  pinMode(CLOCK, OUTPUT);
  pinMode(DATA, OUTPUT);
  pinMode(LATCH, OUTPUT);
  pinMode(RED_LED, OUTPUT);
  analogReference(INTERNAL1V5);

  // initialize boids
  boids[0].position = (point){0, 3};
  boids[0].heading = (vector){1, 0};
  //
  boids[1].position = (point){7, 1};
  boids[1].heading = (vector){-1, 1};
  // 
  boids[2].position = (point){3, 7};
  boids[2].heading = (vector){1, -1};
  // 
  boids[3].position = (point){5, 4};
  boids[3].heading = (vector){-1, 1};

  // initial display
  plotBoids();
  sendImage(image);
}

// send 16 bits to LED tile (bits 0..7 are column, 8..15 are row) 
void sendData(unsigned short data) {
  for(unsigned short i=0; i<16; i++) {
      digitalWrite(DATA, (data & ((unsigned short)1<<i))?HIGH:LOW);
      delayMicroseconds(DELAYTIME);
      digitalWrite(CLOCK,HIGH);
      delayMicroseconds(DELAYTIME);
      digitalWrite(CLOCK,LOW);
  };
  delayMicroseconds(DELAYTIME);
  digitalWrite(LATCH,HIGH);
  delayMicroseconds(DELAYTIME);
  digitalWrite(LATCH,LOW);
}

void setPixel(unsigned short x, unsigned short y) {
  image[y] |= 1 << x;
  if (y > 0)
      sendImage(image);
      delay(10);
  }; // try to compensate for bright col 0
}

// scan an image on the LED tile
// 8x8 bitmap img is the input
void sendImage(unsigned char *img) {
  unsigned short data;
  for(int i=0;i<8;i++) {
      data = (1<<8)<<i;
      data |= *img++;
      sendData(data);
  };
}

void plotBoids() {
  clearScreen();
  for (int i = 0; i < NBOIDS; i++)
      setPixel(boids[i].position.x, boids[i].position.y);
  sendImage(image);
}

struct point handleEdge(struct point p, struct vector d) {
  return {(p.x + d.x)%8, (p.y + d.y)%8};
}

struct vector flock(unsigned short me) {
  vector flocking_vector = (vector){0, 0};

  for(int peer = 0; peer < NBOIDS; peer++) {
      // skip myself  
      if (peer == me) continue;

      // calculate peer x/y distances
      vector peer_vec = (vector){
          boids[peer].position.x - boids[me].position.x,
          boids[peer].position.y - boids[me].position.y
      };

      // look only in flight direction
      if (boids[me].heading.x > 0 && peer_vec.x < 0) continue;
      if (boids[me].heading.x < 0 && peer_vec.x > 0) continue;
      if (boids[me].heading.y > 0 && peer_vec.x < 0) continue;
      if (boids[me].heading.y < 0 && peer_vec.x > 0) continue;

      // handle screen wrap-around, wrap for peers on opposite screen half
      point peer_pos = boids[peer].position;
      if (2 * peer_pos.x > 8) peer_pos.x = 8 - peer_pos.x;
      if (2 * peer_pos.y > 8) peer_pos.y = 8 - peer_pos.y;

      // sum flocking_vector, attraction fades with distance
      if (peer_pos.x < boids[me].position.x)
          flocking_vector.x -= 8/(boids[me].position.x - peer_pos.x);
      if (peer_pos.x > boids[me].position.x)
          flocking_vector.x += 8/peer_vec.x;
      if (peer_pos.y < boids[me].position.y)
          flocking_vector.y -= 8/(boids[me].position.y - peer_pos.y);
      if (peer_pos.y > boids[me].position.y)
          flocking_vector.y += 8/peer_vec.y;   
  };
  return flocking_vector;
}

struct vector avoid(unsigned short me) {

  vector avoidance_vector = (vector){0, 0};

  for(int peer = 0; peer < NBOIDS; peer++) {
      // skip myself  
      if (peer == me) continue;

      // calculate peer x/y distances
      vector peer_vec = (vector){
          boids[peer].position.x - boids[me].position.x,
          boids[peer].position.y - boids[me].position.y
      };

      // look only in flight direction
      if (boids[me].heading.x > 0 && peer_vec.x < 0) continue;
      if (boids[me].heading.x < 0 && peer_vec.x > 0) continue;
      if (boids[me].heading.y > 0 && peer_vec.x < 0) continue;
      if (boids[me].heading.y < 0 && peer_vec.x > 0) continue;

      // avoid() only acts above threshold
      if ( abs(peer_vec.x) <= SEP) {
          // safeguard against division by zero
          if (peer_vec.x == 0) peer_vec.x = -1;
          // if (peer_vec.x == 0) continue;
          // subtract from avoidance vector, move away from peer
          avoidance_vector.x -= 8 / peer_vec.x;
      };
      // avoid() only acts above threshold
      if ( abs(peer_vec.y) <= SEP) {
          // safeguard against division by zero  
          if (peer_vec.y == 0) peer_vec.y = -1;
          // if (peer_vec.y == 0) continue;
          // subtract from avoidance vector, move away from peer
          avoidance_vector.y -= 8 / peer_vec.y;
      };
  };
  return avoidance_vector;
}

void calculateBoids() {
  vector avoid_vec, flock_vec;
  vector sum = {0, 0};

  for (int b = 0; b < NBOIDS; b++) {

       // calculate behaviors
       avoid_vec = avoid(b);
       flock_vec = flock(b);
      
       // weighted sum of behaviors, plus random default direction
       sum.x = random(3) + 3 * flock_vec.x + 2 * avoid_vec.x;
       sum.y = random(2) + 3 * flock_vec.y + 2 * avoid_vec.y;

      /* sum = { 
         random(3) + 3 * flock(b).x + 2 * avoid(b).x,
         random(2) + 3 * flock(b).y + 2 * avoid(b).y 
     }; */

      // make discrete heading
      boids[b].heading = (vector){
          (sum.x == 0)?0:(sum.x < 0)?-1:1,
          (sum.y == 0)?0:(sum.y < 0)?-1:1      
      };

      // update position
      boids[b].position = handleEdge(boids[b].position, boids[b].heading);
  };
}

void loop() {
  // toggle red LED on each iteration
  digitalWrite(RED_LED, !digitalRead(RED_LED));
  if (random(10) < 2) randomSeed(analogRead(AIN));

  calculateBoids();
  plotBoids();

  delay(15);
}

These Ruckus boxes have an amazing beamforming antenna array inside and the VF2825 actually has LEDs on the antenna PCB that shine through a translucent window on top of the unit so that you can see which of the antennas are switched on at any given moment. The LEDs are pointing like a compass needle to the client that it talks to, in many cases, but reflections from the concrete walls in my house seem to spoil that effect a bit.

The VF2111 hasn’t got these LEDs, this had to be fixed of course. It was time to heat up the soldering iron!

On Ebay I ordered a couple of 0402 green SMD LEDs. Well, I quickly realized two things:

• 0402 surface mount packages are way too small for comfort.
• The SMT technology used in the Ruckus seem to be the larger 0603, not 0402. Which would, of course, have been less of a pain to solder.

Breathing carefully, I did manage to mount the six leds to the board, as you can see in the picture above. I only dropped three LEDs in the process, of course making them disappear forever. One PCB pad was lifted when removing the resistors that were populated on the PCB in place of the LEDs. After some micro-surgery with an Xacto knife I did manage to save the pad, though.

More Blinkenlights in the house!

I have located the console port of the VF2111 already, maybe I find the time this weekend to get a shell on the box and poke around some more. I hope the beamforming that these boxes do can make for an interesting WiFi radarscope after some hacking.

To be continued…

So, I made two additions to my stable of practical Bash functions:

match_field() Returns a boolean value when a field in a line matches a pattern:

1
2
3
4
5

# match_field <fieldnum> <RE> <line> ; match field in line
function match_field() {
  nf=${1}; re=${2}; shift 2;
  [[ ${!nf} =~ ${re} ]]
}

extract_field() Is a bit like cut, it prints the content of a field in a line:

1
2

# extract_field <fieldnum> <line> ; extract field from line
function extract_field() { nf=${1}; shift; echo ${!nf}; }

Both abuse positional parameters to select fields, expect this to break horribly when using other field separators than default $IFS.

These can be used to make many of the common cut and awk constructs that probably many of us use over and over again:

1
2
3
4
5
6
7
8
9

while read line
do
  if match_field 2 "foo" ${line}
  then
      foo=$(extract_field 1 ${line})
      bar=$(extract_field 3 ${line})
      echo ${bar} ${foo}
  fi
done < ${somefile}

This is equivalent to the awk script:

1
2
3

  ($2 ~ /foo/) {
      print $1, $3;
  }

Not really more efficient in lines of code, indeed. It doesn’t require forking awk, though. So in tight loops, this might be a bit more easy on system resources. That is all moot because this was just another exercise in going Bash all the way. :)

ca.sh Is a one-dimensional elementary cellular automaton written in Bash. This implementation uses a string of binary digits to store its world in a variable called states.

The following function reads this variable to lookup the states of a cell and its immediate neighbours:

1
2
3
4
5
6
7
8
9

# neigh <cell index> : returns neighbourhood state as integer
function neigh() {
        # cell(n - 1), wrap on edge
        state=$((4 * ${states:(${1} == 0)?${#states} - 1:${1} - 1:1}))
        # self
        state=$((state + 2 * ${states:${1}:1}))
        # cell(n + 1), wrap on edge
        echo $((state + ${states:(${1} == (${#states} - 1))?0:${1} + 1:1}))
}

Even with the comments this makes for some nice Bash code golf. I think the if-statements of the shell are plain ugly, so in this case I used the conditional operator to wrap around the begin and end of the string in states when looking up the states of the cells on the far left and right.

The value of the neighbourhood can then be fed to ca() which does return the next state for a cell based on the current rule number:

1
2
3
4

# ca <state> <rule> : returns new binary state for cell
function ca() {
        echo $(((${2}>>${1})&1));
}

Yup, that’s right, Bash has bitwise operators. :)

These two functions can then be combined like so to display succesive generations op the automaton:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# run ca algorithm
for ((;;)) {
        # display current state using ANSI colors
        display=${states//0/$'\e[0;30;44m '}
        echo ${display//1/$'\e[0;30;45m '}

        next_states=""

        # update cells
        for((c=0;c < ${#states};c++)) {
                next_states=${next_states}$(ca $(neigh ${c}) ${rule})
        }

        states=${next_states}
}

As you can see, I used a regular-expression replace to change the values in states to spaces with an ANSI escape sequence defined background color. Pretty elegant, I think. Although I don’t like the temporary variable display too much.

The full code of ca.sh is included below the break:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

#!/bin/bash
# ca.sh - 1D elementary cellular automaton
# Hessel Schut, hessel@isquared.nl, 2013-02-16

# defaults to rule 30 when no argument given
rule=${1:-30}

# cleanup terminal after the mess we've made
trap cleanup TERM EXIT INT;
function cleanup() {
  # simple reset should be enough
  echo -n $'\ec'
  exit
}

# cellular automaton: ca <state> <rule> returns new state for cell
function ca() {
  echo $(((${2}>>${1})&1));
}

# neigh <cell> : returns integer neighbourhood state
function neigh() {
  # cell(n - 1), wrap on edge
  state=$((4 * ${states:(${1} == 0)?${#states} - 1:${1} - 1:1}))
  # self
  state=$((state + 2 * ${states:${1}:1}))
  # cell(n + 1), wrap on edge
  echo $((state + ${states:(${1} == (${#states} - 1))?0:${1} + 1:1}))
}  

# combined ca() and neigh(), saves expensive function call
function ca() {
  # cell(n - 1), wrap on edge
  state=$((4 * ${states:(${1} == 0)?${#states} - 1:${1} - 1:1}))
  # self
  state=$((state + 2 * ${states:${1}:1}))
  # cell(n + 1), wrap on edge
  state=$((state + ${states:(${1} == (${#states} - 1))?0:${1} + 1:1}))
  # return new state based on rule in ${2}
  echo $(((${2}>>state)&1))
}  

# tput is for weenies, query terminal for its size
function term_size() {
  {
      read -p $'\e[18t' -s -r -d t s;
  } <> /dev/tty
  echo ${s#*;};
}

# extract columns from terminal size
cols=${COLUMNS:-$(s=$(term_size) && echo ${s/*;})}

# initialize states with single cell
states=""
for ((i = 0; i <= cols; i++)) {
  # only set one cell in the middle of the screen
  # all others will be dead initially
  states=${states}$(((i == cols/2)?1:0))
}

# run ca algorithm
for ((;;)) {
  # display current state using ANSI colors
  display=${states//0/$'\e[0;30;44m '}
  echo ${display//1/$'\e[0;30;45m '}

  next_states=""

  # update cells
  for((c = 0; c < ${#states}; c++)) {
      # next_states=${next_states}$(ca $(neigh ${c}) ${rule})
      # second ca() definition used, executes a bit faster
      next_states=${next_states}$(ca ${c} ${rule})
  }

  # synchronize states
  states=${next_states}
}

I wanted to use these to redraw the screen on a window resize in a new Bash hack that I’m working on. Like so:

1
2
3
4
5

trap on_resize SIGWINCH
function on_resize() {
  do_stuff ${COLUMNS} ${LINES}
  # ...etc.
}

As some sort of masochistic challenge, I’m using only pure Bash, no external commands, in the program I’m working on. So I had to come up with a way to get the dimensions of the terminal screen without resorting to tput.

The terminal escape sequence ESC-[18t makes the terminal respond with its dimensions. This can be used in the following way to query the terminal for its size:

1
2
3
4

function term_size () {
  { echo -ne \\e[18t && read -s -r -d t size; } <> /dev/tty
  echo ${size#*;}
}

For example:

hessch@substrate:~$ term_size
51;72

Update: The function above hangs on the read in some cases. Echoing using read -p is more elegant and does not suffer from hanging. Also especially on some versions of MacOS X echo -ne doesn’t grok \e for escape. The following works better:

1
2
3
4
5
6

function term_size() {
  {
      read -p $'\e[18t' -s -r -d t size }
  } <> /dev/tty
  echo ${size#*;};
}

The following two functions help accessing either the columns or the rows part:

1
2
3
4
5
6
7

function term_cols () {
    s=$(term_size); echo ${s/*;}
}

function term_rows () {
    s=$(term_size); echo ${s/;*}
}

These can be used as default values when the variables COLUMNS and LINES are unset. Like so:

hessch@substrate:~$ echo ${COLUMNS:-$(term_cols)}
72
hessch@substrate:~$ echo ${LINES:-$(term_rows)}
51

That saves some useless terminal I/O when COLUMNS and LINES are available.