Long time, no update

The last update here was back in October, after we got the Lancer.

It’s not that I don’t want to maintain the blog, but it’s a reflection of how busy I’ve been with work and other stuff.

My most recent tinkering was with the sensors I’ve attached to our solar hot water system, to log its temperatures on the roof collector, at the bottom of the tank (which are what it uses for controlling a pump on it’s own), and adding some sensors to the take off lines to the house and flat, and return line.

The first rendition had it using TTL signals over telephone cable on 20m distance. It worked, but wasn’t without issue – the comms would have missing bits in the data being sent, so I programmed the software to work with it whilst I figured a better solution. Yes, it is indeed possible to get reliable enough data even with many letters missing.

The change recently to that setup was adding RS485 communication, which is far more resilent to noise and designed for the long haul. I took a leaf out of the systems I use at work, which is that RS485 is capable of long distance communication and at high speeds.

There was significant pain in getting that to work, in my testing I was getting corrupt data each time I tested, regardless of how I hooked up. It was very odd. I then got to thinking that I’ll measure the frequency to ground for one of the pairs. I read 50Hz. Hmm.. I didn’t know USB supply was 50Hz.. anyway, I immediately thought of the only source for 50Hz in my test cases was through the laptop charger to mains..

I took out the charger off the laptop, and viola, reliable data straight away. Many hours wasted on that, but, a hard lesson learned – beware of mains interference through ground. That is one which I’m sure I’ll be able to apply again, but it was a hard learnt one, the weekend and then some wasted troubleshooting that issue (I didn’t think to check frequency until I was very tired of it).

I also took a large stab some months ago at the communication protocol used in the Lancers, it’s very easy to use and provides usable data – which contributes to making the car easily tuned.

As for work, it’s keeping me busy. But there’s a time not long ago that I was very frustrated and convinced I wasn’t going to hang around with all the IT support requests I was receiving that were just purely annoying. And it’s internal support. I don’t think it’s overly the support requests that were the problem, just the increasing workload that those interruptions continually caused.

It’s very difficult, regardless of task to get anything done if you are disrupted every so often with calls of a repetitive nature.

It’s unfortunate that I am being kept busy as well, it means that things that I really wanted to work got neglected, such as our backyard gardens – they’ve got overgrown due to no care at all, and our fruit tree collection is trying to thrive with minimal input.

We are still trying to get some inroads into modifying the interior of our house and extending it. We’ve got a plan that we believe will work, and can sort of make a start on it. I can’t wait to get stuck into tearing up the bathroom, it’ll mean I get a break off work for a bit and get stuck into it. That’d be really nice. Then the plan is to get the exterior of the extension built up and I can then have some fun fitting that out, new kitchen, decent loungeroom.. I can’t wait for that.

I’ve always got some ideas to tinker with as well. I’ll need to find a way to see them through to completion, one of the issues I have…

This entry was posted in Random. Bookmark the permalink.

2 Responses to Long time, no update

  1. Neil Duncan says:

    Hi there – I amtrying to resolve a compilation error experienced when using the Gertboard with the Debian Arduino IDE. The error(s) “#error This version of SoftwareSerial supports only 20, 16 and 8MHz processors” come from the SoftwareSerial.cpp file where there is no entry for a 12Mhz cpu. Do you have any suggestions as to what I need to include for this speed.

    Could I modify the entry for 8000000 which reads:

    #elif F_CPU == 8000000

    static const DELAY_TABLE table[] PROGMEM =
    {
    // baud rxcenter rxintra rxstop tx
    { 115200, 1, 5, 5, 3, },
    { 57600, 1, 15, 15, 13, },
    { 38400, 2, 25, 26, 23, },
    { 31250, 7, 32, 33, 29, },
    { 28800, 11, 35, 35, 32, },
    { 19200, 20, 55, 55, 52, },
    { 14400, 30, 75, 75, 72, },
    { 9600, 50, 114, 114, 112, },
    { 4800, 110, 233, 233, 230, },
    { 2400, 229, 472, 472, 469, },
    { 1200, 467, 948, 948, 945, },
    { 600, 948, 1895, 1895, 1890, },
    { 300, 1895, 3805, 3805, 3802, },
    };

    const int XMIT_START_ADJUSTMENT = 4;

    This must be frustrating all Gertboard users and would help Arduino also.

  2. See this link:
    http://wiblocks.luciani.org/docs/app-notes/software-serial.html

    There’s a simple enough change required for 12Mhz

Leave a Reply

Your email address will not be published. Required fields are marked *

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