VirtualBox and greater screen resolution on the Guest

Julho 12th, 2011

If you’re in the automation field and work with Siemens WinCC software, you have most certainly got projects with different screen resolutions; and screen resolutions are chosen and fixed on the design side. Wich means that if you have to work on a project in a computer with a smaller resolution, you simply can’t see all of the WinCC runtime screen.

Nowadays, I work from my MacBookPro and virtualize Windows and Linux everytime I need them for testing. This is also a very confortable way of dealing with these Windows-only situations like WinCC, but if you’re on VirtualBox and need a higher resolution to work with WinCC (1280×1024 in my case), you’re in trouble. That’s because by default VirtualBox does not allow the guest Windows to pick a resolution greater than the host OS’s.

There is a simple solution, although a bit burried in the manual: just copy-paste this into the terminal:

VBoxManage setextradata global GUI/MaxGuestResolution any

, and suddenly (well, after a guest OS reboot) you can pick humongous resolutions if you want. Then, activate the Scale Mode (Host key + G) and away you go!

To infinity and beyond!

Junho 1st, 2011

Ever since I was a kid I’ve wanted to send a probe of mine into near space. When I grew up and learned a bit more about the laws the govern the universe (at least the ones we can come up with nowadays), I realized it was not an easy task. But I didn’t want to send a full-fledged, 3-year-of-development, 1.5 ton, 3 meter tall probe into space, with the highest tech equipment on board. I just wanted a small probe, with simple, cheap sensors, a camera and little else.

A group of very clever people actually achieved this recentely: the SpaceBits project. Go there and amaze yourself.

Now, the idea of using a high altitute baloon is great, one that I also had myself back then, but not as the only means of transport. My design was based on vessel with propulsion, albeit a very weak one (to be as light as possible). The baloon rises the vessel to a certain height before bursting; the idea was to use the propulsion to go further than the baloon alone could go. The strategy was to use the propulsion a few seconds before the baloon burst to alleviate some effective weight and accelerate the set. The vessel would apply just enough power to even out it’s own wheight, or a bit more, so that the baloon would accelerate. Immediately after the baloon burst, the vessel would apply full propulsion until the power ran out. After that, it would fall again to Earth.

The fall was not caotic; the vessel could manouver during the descent, so that it could crash into a more-or-less predicted place (preferably some water, hehe). I wanted it to have a small parachute, but weight would certainly not allow it (and it’s associated firing mecanism).

I even had a sketch of the vessel made; it had a rocket-like shell, with stabilizer fins, and lateral duct-fan assemblies for propulsion. The body/fins would move to steer the vessel. I knew the fans would only work up to a certain height, but I never got to know what that limit was… if I’m thinking correctly, once the air becomes more and more rarified, the fans produce less and less impulsion; even assuming an infinte power supply, there would be a point were the impulse would equal gravity, and the vessel would move no further.

In terms of power, the idea was for it to be totally electric, with four power supplies: propulsion engines, ascent and descent control motion, main systems, and a very small backup for the main systems.

In terms of sensors, I never got to think too much about it, just some simple temperature, pressure, light, oxygen, altitude, speed, etc. It would have a camera facing forwards, GPS for positioning, and a radio telemetry and control system connected to a land-based application.

Back then, this would obviously all be done with an Amiga! :) Seriously, this was a project I would really like to build one day; electronics are much cheaper now, we have access to some pretty advanced microcontrollers and radio devices, and development (both hardware and software) has never been so much fun! :)

Idiotices estatais

Maio 25th, 2011

O estado dá um incentivo na compra de painéis solares para aquecimento de água de uma habitação. Parece-me boa ideia. Aliás, tão boa que equipei a minha casa nova com um sistema solar poderoso, apoiado por uma caldeira a lenha. Um sistema com um ciclo de carbono perfeito em termos de consumos. No entanto, o estado não me deixa aceder ao incentivo! Parece que comprei os painéis durante a construção da casa, enquanto esta ainda não estava registada (porque não podia, duh)… pelo que não posso declarar a compra no IRS para ter o incentivo. :o

Absurdo. Como se já não bastasse o incentivo ser uma percentagem do valor investido, mas com um limite ridículo (777€ se não me engano). Faz-me lembrar os incentivos para a microgeração, com todos os limites impostos, tanto em termos de registo de instalações como nos preços pagos por KWh. Na prática, é tudo uma fantochada. Como muitas coisas anunciadas neste país.

Enfim! :P

Performance versus Beauty

Abril 6th, 2011

I believe programming is an art. Just like an artisan creates an artifact, when I program I develop… and item. Although intangible (most of the time), it normally has a visual form (the application’s HMI, or Human-Machine Interface). This visual aspect should be coherent with the rest of the product, admirable, intriguing, exquisite.

Designing a good User Interface is an art in itself, one that should “connect” with the intangible part of the “machine”. When they blend, they can really amaze, entertain, inform, in a simple, natural (yet powerful) way.

My home automation is badly needing love in this area. The intangible part is coming along very well, but I really need to dedicate myself to the User Interface. I’ve made sure it is functionally quick to respond and simple to extend, but I’ve delayed the visual design a bit too much. I think I’m in a point where functionality is at a very interesting level, and as soon as I finish the element I’m working on (the air admission system, including an earth-air heat exchanger) I’ll shift to design.

I’m aiming at simplicity and usability, something not trivial to achieve when your system crosses a certain sofistication threshold.

Time scavenging

Abril 5th, 2011

You know when you’re playing this great action game that has you doing some amazing stuff, but you have limited time to accomplish your mission? Once in a while, you come against these beautiful clocks just floating there in the air… up for grabs. You pick one up and presto! There you go! Another 2 minutes allowance to finish that level.

Since I don’t seem to have time for almost anything these days, I *so* wish I could find those floating clocks around here!…

Resol VBus LAN adapter on Resol DeltaSol C Plus

Março 15th, 2011

I’ve finally received my Resol VBus/LAN adapter! I’ve installed it this weekend on my RigSun solar system and connected it to the home automation so that I can log the system’s data (temperatures and pump states).

It was very easy to integrate, being a simple proxy to the VBus solar controller, with a trivial TCP/IP connection protocol. The VBus binary protocol was easier to implement than I thought inicially. I’ve developed a cool class to interface with my solar controller (Resol DeltaSol C Plus), and I can subclass it easily and quickly to accomodate other Resol controllers.

VBus is almost RS-485 (modified to provide parasitic power to the devices on the network, I guess), so it should be simple to make an electronic adapter, but I have no time now to investigate. Later perhaps.

I’ll share the data here, along with a couple of small modifications I’m making to the system.

Nexus 7 (Andromeda) and Interference (Sanity)

Fevereiro 25th, 2011

Just had to leave my tribute here to these two demos that really amazed me when I was a kid… the effects and art were great (the Interference opening image is a classic), the transitions very well thought out, and the music… oh, the music… it is simply brilliant! :o

Nowadays, I always have with me a selection of musics from my Amiga days (I must remember to post the list), and these two are some of the best. Ever.

Hats off to you guys, even if 16 years later! ;)

P.S.: If you were an Amigan back then (this should bring back memories), and want to watch the demos again, just remember: nothing beats the real thing! Get your old Amiga out of storage and boot it up! :)

Fun with the Arduino Ethernet Shield

Fevereiro 23rd, 2011

I’ve been using the Arduino platform as a means to develop some of the devices I’ve been needing, from the most simple (my daughter’s color-changing nightlight) to the most complex (a stand-alone, fault-tolerant, inexpensive telemetrics system). Somewhere along the way, the Ethernet shield come into the picture. To be a part of my designs, I had to tweak a few things on the shield:

* The reset is not dependable; many times the shield would simply not startup as expected, and the Arduino lost connection to the outside World. Solution: I lifted the shield’s reset pin (so that it does not enter it’s connector on the Arduino) and connected pin 8 to the shield’s reset line. Like this I can programmatically reset the shield on every boot, and every time I loose a connection to the Internet.

int rebootEthShield()
Serial.println("Rebooting ethernet shield...");
pinMode(8, OUTPUT);
digitalWrite(8, HIGH);
digitalWrite(8, LOW);
digitalWrite(8, HIGH);

Ethernet.begin(mac, ip, gateway, netmask);

You can obviously choose any other output pin.

* I test the Internet connection by connecting to a server on the outside World (i.e. my server). But since this is hardly a static World, and IPs are apparently volatile entities, I needed to have a means to change the test IP. The problem is, the Arduino does not really support object instantiation. So, you create a client socket like so:

byte cl[] = { 192, 168, 1, 1 };
Client clienteLink(cl, 80);

And that’s it. You can no longer change de IP throughout execution. :( To be able to do it, I had to add a method to the Client class: reconfigure(). On the Client.h file, add:

void reconfigure(uint8_t *, uint16_t);

On the Client.cpp file, add:

void Client::reconfigure(uint8_t *ip, uint16_t port) {
_ip = ip;
_port = port;
_sock = MAX_SOCK_NUM;

This is on Arduino Alpha 022 (older versions need slightly different code, but it’s very simple).

Now, all I need to do is close the Client before issuing a reconfigure(). Then I can try to connect to another server. There may be a simpler way to do this, but I couldn’t find it. If you do, please post! :)

Have fun!

…jumps over the lazy dog!

Fevereiro 17th, 2011

There is one part of the HMI system I did in a somewhat “lazy” way. I’m creating display objects (JFrames, charts) in memory for each of the display elements. While this ends up being a nice tradeoff between memory and speed (changing between elements is near-instantaneous), I should probably reduce the memory footprint of the HMI application.

Then again, this version has quite a lot going on (charts, threads, etc), and I should probably leave it alone and develop an alternate, slimmed-down version (to run on embedded and tablet machines). Without charts or Swing widgets, pure raster graphics, like a game. After all, I won’t need charts on every element in every control point of the home automation. Most of the time I just want an overview of the house, give some commands, check out the results, and be done with it. Quickly. If I must analyse something, the historic screen is a very capable tool.

Next up, is creating a simple, yet good Web-based interface, or at least a simple dashboard. Check out this project’s web interface, it’s really cool!

And while I’m at it, create a version of the server app without the JFrame… and a socket I can connect to to send commands (Start/Stop).

The quick brown fox…

Fevereiro 10th, 2011

In your home, when you touch a button, you expect the associated lamp to light immediately. For example, if you open the door to your basement, you need light right now to go down the stairs safely. Waiting a couple of seconds for the lamp to light is not expected, nor desirable. After all, the most basic and primitive lighting controls work directly on the power source, and act immediately, so when you have a state-of-the-art home automation system installed you expect the very same performance.

But, from a developer point-of-view, when you have a network of almost 20 nodes, you need to pay close attention to your data paths if you want to achieve lightning-fast response times. I’m working on the near-realtime domain, but I need to be as close as possible to real-time.

So, I’ve been finetuning my home automation’s data subsystem. I think is it of the utmost importance that the controls feel immediate, quick and nimble. And the physical controls (wall buttons) need to behave real-time, or very, very close to it. The HMI (geared towards touch panel use) needs to behave accordingly, and flow at least as fast as your mind can move your finger. That’s why I’ve developed my home automation’s HMI to be that fast.

Usability is a heavily studied subject, but a historically highly neglected one (although nowadays things seem to be improving). Thankfully I’ve had some training on the subject (and I must thank my University teacher that introduced my to the art, she was inspiring), and you can be sure it won’t be neglected.

I’ve had to tweak the data gatherer thread on the server application, adapt the nodes’ firmware, and scatter data polling in the time domain. Talking in numbers, I reached a half-second (median) response time in the physical control buttons, which seems to be perfectly acceptable. This performance is on a 500Mhz AMD K6-III CPU, 196MB RAM, still running under Windows XP. The final target machine will outperform this test-bed in every aspect (and it will not normally run Windows, but a very light Linux distro, AmigaOS, or MacOS X), so I’m quite happy with the results so far.

Obviously, I have a plan B to accelerate this even further if needs be. It involves bypassing each nodes’ polling overhead, by centralizing data in the header node and fetching in one go (asynchronously). Heck, I even have a plan C to respond in the minimum time possible, involving a full duplex protocol on the header node. Plan C will eventually get implemented (once I sort out the asynchronous communication arbitration between nodes), since it is the best way to do it.

Onwards! :)