In Valid Logic

Endlessly expanding technology

A day of hacking later...

After a day of hacking on my idea, I now have some results.

For starters, think I am going to go the AVR route as opposed to PIC.  In checking out the current state of things, AVR seems to be the hot new kid on the block, and PIC is kind of limping, in my opinion.  Their online community is horribly outdated.  The big player that used to be PIClist is now old, out dated, and broken.

While the mini controllers will likely take me some time to get some of the parts and begin hacking on it, I decided to dive into writing the master controller software that will run on the PC.  I have to admit, I am somewhat disappointed... I thought it would be harder, but I already have it working.  Granted, right now it just a coding API, though will add the ability to save/load scripts and maybe, if I really get bored, code a GUI to do the layout.  But as it is right now, have some simple coding looking like this:

static void Main(string[] args)
    Sequence sequence = Sequence.Create();
    Device device = sequence.CreateDevice("");

    LightDurationEvent light1 = sequence.CreateEvent<LightDurationEvent>(device);
    light1.StartTime = 0;
    light1.Channel = 1;
    light1.Duration = 1000;

    LightDurationEvent light2 = sequence.CreateEvent<LightDurationEvent>(device);
    light2.StartTime = 500;
    light2.Channel = 2;
    light2.Duration = 1000;

    LightDurationEvent light3 = sequence.CreateEvent<LightDurationEvent>(device);
    light3.StartTime = 1000;
    light3.Channel = 3;
    light3.Duration = 1000;

    LightDurationEvent light4 = sequence.CreateEvent<LightDurationEvent>(device);
    light4.StartTime = 1500;
    light4.Channel = 4;
    light4.Duration = 1000;


Can also add other event types, such as an AllLightsEvent, which will turn all lights on or off.  Also going to work on making it more extensible, so I can have different types of devices that handle different events... ie, maybe I have a device that controls a servo motor or something.  We'll see.  Right now, most of the implementation details are up to the events.  When Execute is called, it turns the events into a series of commands (ie, turn light on at 0ms and turn it off at 1000ms... 2 commands).  The commands are basically comprised of when they happen, which device the command goes to, and the raw byte[] for the command.  The byte[] is what is actually sent to the device over the network, so allows we to send just about anything to it.

The one thing I haven't got working is broadcasting... I send the commands using UDP, so can do broadcasting/multicasting.  The packets seem to send ok (though not actually running a packet sniffer), but the problem was I couldn't get my test receiver to receive broadcast messages.  Ohh well, no biggie right now.

One thing I should mention... I love generics in C# 2.0... so love them.  The "sequence.CreateEvent<LightDurationEvent>(device)" would otherwise have been "sequence.CreateEvent(typeof(LightDurationEvent), device) as LightDurationEvent".

Going forward, have two concerns:

  • Should I change from UDP to TCP?  Losing packets with UDP could suck, but I think the overhead to handle that in TCP might be too much too.
  • Timing... can see timing becoming an issue when it goes along with music.  Say I turn a light on for 100ms, then turn it off.  I will be on more than 100ms... there the delay with the PC processing, sending over the network, and the mini-controllers acting on the command.  Probably very minute, but when there is a long series of commands, closely tied to music, wonder if it would cause them to get out of sync.  Moving to a dedicated master controller (non PC) may be better option eventually.  Less going on, so likely would be easier to calculate the clock costs of the code and compensate with adjusting the timing between commands.

Thursday, November 30, 2006

blog comments powered by Disqus