After Eric VDB pointed me to Codeshare in a comment on a previous post, I couldn’t resist searching for something that could help me get started.

And I found something useful here. Although the example that came with it was targeted for a Gadgeteer Extender Module (which I don’t have), I had no problems getting it to work. I created an additional constructor that would accept pin numbers, like this:

SerialLCDDisplay lcd = new SerialLCDDisplay(
                     FEZ_Pin.Digital.Di21, // RS
                     FEZ_Pin.Digital.Di23, // ENABLE
                     FEZ_Pin.Digital.Di25, // DB4
                     FEZ_Pin.Digital.Di27, // DB5
                     FEZ_Pin.Digital.Di29, // DB6
                     FEZ_Pin.Digital.Di31); // DB7

It took me some time to figure that out, but within the hour I had the LCD running. I added an endless loop with an increasing counter and a delay of 1 second and let the sketch program run; at the time I took the picture it had been running for more than 4 hours.

One thing I noticed was that the LCD sometimes displayed garbage when the Panda was rebooted; after that everything worked OK, but startup looked a bit ugly. Maybe give the hardware connected to the Panda some more time to settle? I don’t know yet; we’ll see about that later. Another thing I need to have a look at is the fact that this SerialLCDDisplay class was apparently written for an LCD with 2 lines; cause line 0 (first line on the LCD) and 1 (second line on the LCD) were OK, but output destined for line 2 were shown on the first line of the LCD again – probably a minor issue.

And since I’ll have to change the class code for that anyway, I’ll also add 2 additional parameters with which I can set the number of rows and columns of the LCD – cause I have both 20×4 as well as 16×2 LCDs!

Oh, and I saw these automatically generated Debug messages appearing in the Debug output window in Visual Studio on my PC:

GC: 4msec 12132 bytes used, 52248 bytes available
Type 0F (STRING              ):     96 bytes
Type 11 (CLASS               ):   1596 bytes
Type 12 (VALUETYPE           ):     60 bytes
Type 13 (SZARRAY             ):    108 bytes
Type 15 (FREEBLOCK           ):  52248 bytes
Type 17 (ASSEMBLY            ):   7560 bytes
Type 18 (WEAKCLASS           ):     48 bytes
Type 19 (REFLECTION          ):     24 bytes
Type 1B (DELEGATE_HEAD       ):     72 bytes
Type 1D (OBJECT_TO_EVENT     ):    168 bytes
Type 1E (BINARY_BLOB_HEAD    ):    156 bytes
Type 1F (THREAD              ):    384 bytes
Type 20 (SUBTHREAD           ):     48 bytes
Type 21 (STACK_FRAME         ):    828 bytes
Type 27 (FINALIZER_HEAD      ):    168 bytes
Type 31 (IO_PORT             ):    252 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):    492 bytes

This must be some diagnostic information from the GC process kicking in. 12 KB used? Woow… that’s 20%. But what’s the baseline of used memory, e.g. what does a program with an ‘empty’ main() use in terms of memory? Sounds like a good subject for another post..

Share/Bookmark

I found a tutorial on how to do I2C with the .Net MF and used that one as a starting point. It didn’t take long before I found out that for me, in this case, it was easier to rely on the TSL2561 datasheet than to try to use someone else’s code to create my first C# class for this sensor.

Probably because this first try was an easy one; I guess in the future, when things become more complicated, I’ll have to take some peeks at how others do certain things. But for now, I’m pleased with how this first exercise worked out!

The code is not finished yet, but it’s in a stage where it works and produces the raw data coming from the data registers. Good enough for a post

Here’s a small piece (the constructor part) of the class code:

public TSL2561(byte I2CAddress, int ClockinKHz)
{
  I2CConfig = new I2CDevice.Configuration(I2CAddress, ClockinKHz);
  I2C = new I2CDevice(I2CConfig);
 
  // read the ID register.
  var Actions = new I2CDevice.I2CTransaction[2];
  byte[] rx = new byte[1];
  Actions[0] = I2CDevice.CreateWriteTransaction(new byte[] { 0x0a });
  Actions[1] = I2CDevice.CreateReadTransaction(rx);
  if (I2C.Execute(Actions, 1000) == 0)
  {
    Debug.Print("Read ID Register failed");
    // exit or something
  }
  else
  {
    Debug.Print("ID value: " + rx[0].ToString());
  }
  // 4 msb must be 0001 for a TSL2561
  if ((rx[0] & 0xf0) != 0xa0)
  {
    // exit or something
  }
 
  setGain(0x10);
  Thread.Sleep(5);   // Mandatory after each Write transaction !!!
}

Not that bad if I may say so…

The sensor is being read every 5 seconds and this produces the following output, where it shows the decimal values of low and high bytes of both ADC channels:

--------------
Result: 156 1
Result: 69 5
--------------
Result: 160 1
Result: 80 5
--------------
Result: 174 1
Result: 114 5
--------------
Result: 177 1
Result: 119 5
--------------

Nice! Calculations with these numbers is something that’s on the to-do list for now, but that should not give any big problems anymore; no, but what I think will be the biggest obstacle to overcome is my knowledge of C#.

For example, I’m used to displaying numbers in hexadecimal format. So I added a x.ToString(“X2″) (where x is a byte) in a Debug.Print(), knowing I’ve used this before myself in VB.Net and have seen this being used in C# too – I got no build errors, but I did get an exception… apparently the .Net Micro Framework doesn’t support this? I have to press F1 for help too much for my taste.. A matter of learning on the job I guess..

Now let’s see if I can find that 20×4 LCD for my next ‘project’; and maybe a spare LCD Plug, to keep the number of wires acceptable.

Share/Bookmark

Another gadget to tinker with arrived yesterday; a  FEZ Panda II from GHI Electronics. Arduino pin compatible, compatible with most Arduino shields, 72 MHz 32-bit CPU, 512 KB flash, 62 KB RAM for application, Micro SD socket, RTC and more, much more.

It’s a bit bigger though; the length is about  10 mm more than the Duemilanove.

The FEZ Panda II runs on the .NET Micro Framework and you can program (and even debug) the Panda with Microsoft Visual C# Express (free). Deployment to the Panda is done from within the Visual Studio IDE, and setting breakpoints, stepping and adding watches all (seem to) work. I got a ‘blinking LED’ example up and running in no-time – downloading and installing the .NET Micro Framework 4.1 and the GHI NETMF 4.1 cost me more time than getting the LED to blink; so far this looks OK.

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.Hardware;
using GHIElectronics.NETMF.FEZ;
 
namespace MFConsoleApplication1
{
  public class Program
  {
    public static void Main()
    {
      OutputPort LED;
      LED = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.LED, true);
      while (true)
      {
          LED.Write(true);
          Thread.Sleep(20);
          LED.Write(false);
          Thread.Sleep(2000);
      }
    }
  }
}

Why did I buy this FEZ Panda II? Well, for the fun of it ofcourse! And second, I wanna know more about these kind of devices and check some of the statements made.

For instance, the statement that the Panda is compatible with most Arduino shields intrigues me; to what extent is this true? “The shield fits in the headers” is not enough ofcourse; most shields come with a library to support the hardware that’s on the shield, but those libraries are for the Arduino platform, so how easy is it to plug in a Arduino shield and get it  really working? Can, and if so, how hard is it to port Arduino code to this C# environment?

Another thing is: how does the .NET runtime influence time critical I/O, where output pins have to be switched very fast? How does this Panda perform, knowing there’s an additional layer (the CLR, Common Language Runtime) between the C# code and the bare hardware?

And how about memory usage? 62 KB user memory may sound like a lot compared to the Arduinos 2 KB. OTOH, when I compare my VB.Net touchscreen application to my Delphi Domotica system, the memory usage of the first one is huge compared to the 1.3 MB my Domotica system uses. So what will using a .Net environment do in this particular case? Will adding a few hardware drivers to a C# program quickly make the available memory vanish, or what?

And I’m also interested in how I will perform with C#; I hope that seeing/writing code in all kinds of programming languages from the early 80′s will help me to get started

Questions, questions… which I hope to be able to answer in the next weeks; I was getting bored with watching that blinking LED on the Panda II, so I decided my first “Panda project” will be an I2C exercise with a JeeLabs Lux Plug to see how hard (or easy) it is to talk I2C with this sensor. And if all goes well, next thing will be to write some text on a spare 20×4 LCD I have one laying around. Those sound like some good beginner projects, right?

And if both succeed, the 2.8″ TFT LCD Touchscreen I bought recently, will be next.

That’s it for now; new challenges are waiting!

Share/Bookmark

For starters I made a small sketch with just a string, 3 ‘touchable’ areas and an icon. The first challenge was making the drawLine() function from the library working; somehow it had problems with drawing the left side of the roof of the ‘home’ icon. No clue why, but it just didn’t work. Only after I changed the parameter types from unsigned int to int and replaced the algorithm with the simplified version of the Bresenham line algorithm the home was correctly drawn.

Next thing I did was printing some touch related information to the Serial and this is what I saw:

X = 611, Y = 442, P = 575
X = 609, Y = 443, P = 536
X = 606, Y = 444, P = 507
X = 599, Y = 447, P = 457
X = 599, Y = 447, P = 449
X = 600, Y = 440, P = 486
X = 601, Y = 434, P = 522
X = 642, Y = 604, P = 470
X = 634, Y = 609, P = 468

Well, so far so good… on to the next phase!

Share/Bookmark

My biggest concern was whether this new Pace box would still work my Pronto/IRTrans combo; would it accept the same Infrared (IR) codes as the Thomson? A quick test revealed that the old Thomson remote could be used to control the new Pace, so at that point I didn’t expect any problems.

Later that evening, when I used the Pronto to control the Pace mediabox, I discovered that the “CH+” and “CH-” buttons of the Pronto didn’t work anymore. To be precise: the first “CH+” did work, but the second time it didn’t…huh? The “CH-” had the same wierd behavior.. first push OK, the second was ignored; and the 3rd, 4th… So selecting a channel with a digit (0..9) did work as before, but zapping through all the channels didn’t? What the ….?

Hmm, time for some investigation. First thing I did was trying to find the Pronto CCF codes for this new model, but that didn’t help. Later I found out that this Pace uses the same IR codes as a Philips DCR-8111 but I couldn’t find any IR codes for that model either.

Well, back to the original symptom then – why do the CH-buttons only work once? After some time I found the cause in a post on the L5 remote forum:

Parity & Toggle Bits
A somewhat common problem is when a device (such as a cable box) will accept a learned code once but not twice in a row. For instance, you can enter the channel “1 – 2″, but not “3 – 3″. This is not a fault with your new remote, but rather a very hard to work with design employed by your equipment.
What happens is your original remote tacks on a “parity bit” (sometimes called a “toggle bit”) to the end of each code. So, the first time it sends the code it follows up with a “0″. The next time it ends with “1″. The problem is that a learning remote can only learn or send the signal one way – the way it learned it. Your equipment, unfortunately, will not accept the code again unless it ends with a new parity bit or you send a different code to clear the memory buffer.

The most common example of equipment that uses this system is anything that employs the Philips RC5 or RC6 code format – such as Philips or Marantz products, or even Microsoft Media Center Edition remote controls. As the RC5 and RC6 implementation guidelines make parity bit checking optional, not all RC5/RC6 devices will respond the same way to non-alternating learned codes. Some may require parity bits at all times, some may only require it for certain commands (such as “power”), some may use the parity bit only for closely repeated commands (meaning you could send “3-3-3″ quickly with the original remote but only slower using a learned code), while some ignore parity bits completely and show no noticable operational difference with or without.

The Philips Pronto is the only remote that I am aware of that can learn codes with alternating parity bits in the method required for several (not all) brands of equipment. If you have one that is not yet covered you can try tacking on a “do-nothing” code after each real one. So, your button for “3″ would send the “3″ code followed by another code to clear the buffer. What can that code be? Anything that the equipment senses as a real code but doesn’t affect operation. It may be next to impossible to find such a code.

Great, this sounds exactly as what I’m experiencing. Parity (toggle) bits… and the new Pace doesn’t ignore them!

Now that I know what is causing my problem and how it works, I should be able to create a workaround; I can stop searching for the correct IR codes for the CH+/CH- buttons, because a single IR code for a CH button will never work. Instead, I will need to get hold of both IR code ‘versions’ for a single CH button and make sure my system will automatically alternate between those 2 versions.

How do I get those 2 codes for a single button? Well,  PEP1 (Pronto Edit Professional v1) and a Pronto Remote (a TSU9600 in my case) enables you to learn a IR code. So that’s what I did; I learned  a couple of CH+ IR codes, copied the resulting CCF codes to a text editor and searched for differences; and found the 2 different versions for CH+:

[up1][CCF]
0000 0072 0024 0000 000F 000A 0006 000A 0006 0016 0006 000A 0006 000A 0006
001C 0006 000A 0006 000A 0006 000A 0006 0016 0006 0016 0006 0010 0006 0016
0006 000A 0006 0016 0006 000A 0006 000A 0006 0CB7 000F 000A 0006 000A 0006
0016 0006 000A 0006 000A 0006 001C 0006 000A 0006 000A 0006 000A 0006 0016
0006 0016 0006 0010 0006 0016 0006 000A 0006 0016 0006 000A 0006 000A 0006
BEA1

[up2][CCF]
0000 0072 0024 0000 000F 000A 0006 000A 0006 0016 0006 000A 0006 000A 0006
001C 0006 000A 0006 000A 0006 000A 0006 000A 0006 0016 0006 0010 0006 0016
0006 000A 0006 0016 0006 000A 0006 000A 0006 0CB7 000F 000A 0006 000A 0006
0016 0006 000A 0006 000A 0006 001C 0006 000A 0006 000A 0006 000A 0006 000A
0006 0016 0006 0010 0006 0016 0006 000A 0006 0016 0006 000A 0006 000A 0006
BEA1

There’s definitely a difference between those 2 codes, marked in red; so far things are looking good. Now it’s time to test these 2 codes by sending a up1, up2, up1, up2 IR sequence to the Pace mediabox. Yep; the channel increased 4 times – it worked!

The rest is simple. My system uses the IRTRans ASCII interface protocol for sending IR with the IRTrans LAN module. The IR commands that can be used are not predefined in my Domotica system however; they are retrieved from the IRTrans by using the Agetremotes and Agetcommands commands. So all I have to do is ‘tag’ the 2 ‘up’ commands in a way that my system can figure out that there are 2 commands for ‘up’. For example, I could name them [up#1] and [up#2] and let the system pick the right ‘up’ version and send the right ‘up’ command (up#1, up#2) to the IRTrans with the Asnd command whenever a UI sends a ‘up’ request..

No need to change anything at UI level and 10 lines of code should suffice. Problem solved!

Share/Bookmark

Should I buy a tablet and put it on the wall? Neh, too pricy and therefore not expandable enough – we would be bankrupt before I could finish this project .

Or is it better to create a User Interface for the smartphones? Useless for this particular ‘problem’, cause we all have the habit of leaving our smartphones downstairs – no one has the urge to Tweet or call while in bed (yet…). Besides that, guests in our house should also be able to lower a roller shutter without too much hassle.

What I’d like to have is something small & simple, touch-driven, communicating wirelessly, with an easily adjustable User Interface without having to change the code too often and, if possible, suitable to take in your hands.

For that I bought this Touch Shield to tinker with during the next weeks. There are some nice videos that demonstrate what you can do with these Touch shields and they look well enough to give it a try. This particular shield can be used with the Adafruit library, which takes care of the low level stuff and provides functions for stuff like drawing lines, circles, rectangles and text on the screen – with an SD card it should even be possible to draw 24-bit BMP files – well, let that be be step 2 for now.

While this Touch Shield is on its way, I started thinking of how to make this Touch Shield cooperate with my Domotica system. As I said, I don’t want to change the sketch when I want to add another menu option or button or anything else that comes to my mind; the ‘definition’ of the screens, menus, buttons should not be defined in the sketch, but somewhere else. Preferably somewhere on the network in a file; another good option could be stored on a SD card.

This file should contain everything that can be regarded as being subject to change when multiple Touch Shields are going to be used throughout the house: menu options, shapes, buttons, colors, text, actions; so the basic idea is: 1 sketch which can handle multiple User Interface definitions, designed for a specific location/room. So I definitely need some sort of User Interface Markup language for that, like XAML is.  But the markup language to be used should also be really ultra-light-weight, cause we’re still dealing with an Arduino here, where RAM is limited and every bit of overhead leads to problems, very quickly. I mean, you could define a button like this:

<Button Background="Red" Foreground="Green" Content="Light on" Action="C02 ON"/>

but that will consume more memory than

B;BRED;FGREEN;TLight On;AC02 ON

So maybe I’ll create my own Markup ‘language’; we’ll see.

The way in which an action will be communicated with my Domotica system will be something comparable to how our Ethernet Doorbell communicates with the system; for example, when the touch of a button should result in a light going on or off, I can just let the Arduino send a string (the Action property in the examples above) to my system and it will take care of the rest.

Big plans, which also bring a lot of new challenges – and I’m sure, a lot of fun!

Share/Bookmark

Well, it could just as well have been any other color of the 256*256*256 colors these RGB LEDs can produce, but since today is Koninginnedag, Orange was the most appropriate color I could think of for today.

The last 2 days I started with putting these RGB LEDs in the ground, under the gazebo.

Removing the stones to get the 20 meters of cable under the terrace, grit around the poles and putting everything back in place took me 2 days and I’m still not completely done yet; I think I need another afternoon for the ‘finishing touch’.

Just for fun I made a small beginning with controlling these LEDs from my system by using scenarios or lighting sequences; here’s what the “random” color scenario looks like:

I’m also going to use a remote for these RGB LEDs; I still have an old 433 MHz remote with 8 buttons that can be re-used to select the different scenarios. This remote will be attached to one of the poles of the gazebo so we won’t need to go inside to change the lighting.

With the Arduino acting as web-interface to the hardware, my domotica system and this remote I think we can really enjoy these RGB LEDs during those many upcoming long, hot summer nights!

Share/Bookmark

The first thing I did was completing the indoor part of it all, e.g. putting the adapter, DMX decoder, Arduino with 2 shields (DMX & Ethernet) in a enclosure. This whole setup has already been tested with something I developed last summer. It had a Colorwheel control with which it was very easy to pick a color and control the RBG LEDs. But this is not enough; I still needed to integrate those RGB LEDs into my Domotica system. By doing that, my system is now in full control over the RGB LEDs and they can be controlled based on events, from the GUI (touchscreen) in the living room etcetera. This integration involved creating a Device Class for the RGB LEDs and a suitable interface to ‘talk’ to the hardware.

But not all things went as smooth as I had hoped. First, a power adapter cable was broken, which made the whole setup stop working every few minutes or so. It cost me half the afternoon to find out it was just a piece of cable that was bugging me…

I also applied the ‘Ethernet-shield-powered-from-the-adapter-plug’ fix I wrote about before, but it didn’t help enough. Sure, 4 out of 5 times it worked, but not always. And that’s not good enough, so I searched for another solution and I found one here, and this one worked always – well, successfully powering up 30 times in a row convinced me that this works well enough. So now there’s a wire going from the RESET pin to pin 4 (the Ethernet shield is underneath the DMX shield).

The code that comes with it is simple but very effective:

void init_ethernet()
{
 pinMode(DO_RESET_ETH_SHIELD, OUTPUT);      // sets the digital pin as output
 digitalWrite(DO_RESET_ETH_SHIELD, LOW);
 delay(1000);  //for ethernet chip to reset
 digitalWrite(DO_RESET_ETH_SHIELD, HIGH);
 delay(1000);  //for ethernet chip to reset
 pinMode(DO_RESET_ETH_SHIELD, INPUT);      // sets the digital pin input
 delay(1000);  //for ethernet chip to reset
 Ethernet.begin(mac,ip,gateway,subnet);
 delay(1000);  //for ethernet chip to reset
 Ethernet.begin(mac,ip,gateway,subnet);
 delay(1000);  //for ethernet chip to reset
}

Calling the init_ethernet() function from the setup() is all that’s needed to get a fully functional Ethernet Shield. Finally this RGB LED project is finished; well, I still have to dig 6 holes and get the RGB cable under the terrace – after that, summer can begin!

Share/Bookmark

Year    Number of times <= 258W

2008    15
2009    75
2010    60
2011    0
2012    1

I expected this trend, cause 2008 has been the year where I ditched 3 (or was it 4) older PC’s which were on 24/7 by virtualization and also took some other measures to reduce power consumption. 2009 was the year in which we benefited the most from this power reduction but since then, I guess it’s the ever increasing amount of power consuming hardware that made the base power usage (as in during the night, where as much hardware as possible is turned off) increase through the years. The power usage drill-down charts I made in the past confirm all this.

I checked when the last time was when we had a nightly power usage below 258W and it was 16-03-2010! More than 2 years ago… this is no coincidence, and I can think of only 1 thing that can be responsible for matching those 258W last night, after a very long time: reducing the number of adapters.

What else could it be?

Share/Bookmark

I’m just doing some silly moves in front of the camera like lifting my arms etcetera, so nothing spectacular there; it’s the skeleton being displayed on the monitor what’s spectacular, and fun!

Every time I did some tests, the kids came running from the livingroom and started jumping, waving their arms and doing all kinds of crazy stuff

At the end of the video, where I walk back towards my keyboard and the distance to the Kinect reduces to 50 cm or so, you can see that the Kinect is getting a hard time tracking all the joints; it becomes a big mess. But that’s okay.

After tinkering with the Kinect and the Kinect SDK for 8 hours or so, my first impression is better than I expected, acually. The way speech is being recognized, how well a skeleton is being tracked is better then I had expected. Ready for use! Is it, or…?

My goal is to use the Kinect for speech and gesture recognition; for that I want to develop a small, lean and mean app that does just that and that can interface with my Domotica system in some way. Either by adding a TCP server to the app, or by uploading information with XMLRPC, or whatever – haven’t really thought about that yet. But I also need an application to ‘record’ gestures and an easy way to define new speech commands this app should recognize; and not just “light on”, but also commands with variables in them, like “we will be back at 16:00″. My system can handle this kind of ‘dynamic events’, so the Kinect should too, right?

But some other things give me second thoughts about the usability of the Kinect.

First, while I was capturing this video, the CPU usage on my Intel E8200 Core 2 Duo (2.66 GHz) Windows 7 Ultimate PC with 8GB RAM was around 50-60%; that’s rather high. Well, I guess most of the CPU cycles were consumed by displaying the skeleton on the screen (which is something I won’t need in the end), but I really need to know what the remainder of the current 50-70% will be when I strip this app to what it is supposed to do: simply recognizing gestures and speech without UI. Cause I’m not that fond of spending that much processing power (and the power consumption that comes with it) on this.

Second, the SDK is limited to Windows 7 (and above, I guess). That’s too bad; now that I think of it; wouldn’t I be better off with something more versatile, platform independent? Wouldn’t it be ideal to connect a Kinect to some local, low-power processor unit (Raspberry Pi, xyz Plug, etc) and let that device take care of the processing and only communicate “the stuff that matters” to the central system? Hmm, maybe I should have a look at some alternatives as well.

Third, the Kinect uses USB to connect to the PC. What if I want to use more than 1 Kinect, say 2 or 3, throughout the house? How do I fix that, USB and max 5 meters of cable length?

So although I’m impressed by the Kinect, there’s still a huge pile of things to do, discover, explore and.. decide!

Share/Bookmark