Map
Grand Prize Winner
(Dec 2012)
Second Prize Winner
(July 2012)

Spark IO – First Encounter

Searching for a compact, flexible and cost effective WiFi solution for our new project we came across Spark IO This tiny board met all our requirements and looked ideal for our application, however, it was ‘out of stock’ in many if not all online electronic stores. Best we could do was to ‘express interest’ which is really a totally useless thing. The only possible place to get it from was Spark’s own online store so after doing some considerations and failing to find something similar in functionality and price tag we decided to take the risk and order. The parcel arrived in less than two weeks and contained a neat box with Spark IO itself, USB cable and protoboard which was a pleasant surprise. Spark IO visually looked even more compact than we expected. After unpacking and quick visual inspection the next logical step was to try the board in action. The Spark’s website contains comprehensive documentation which describes setup process as quick and painless and it by the way turned out not to be the case. That is a typical ‘chicken and egg’ problem whereby in order to be able to control the board it has to be configured and in order to configure it there is a need to get control. The idea of using a mobile phone as a tool of Spark’s initial configuration is great on the surface but hopeless when something goes wrong or when there are more than one Spark core awaiting configuration. Ironically, the fallback plan that is intended to help with configuration hurdles is just not good enough. Let’s have a closer look at potential difficulties with board’s first connection.

In order to get configured, Spark core a) has to be programmed with valid WiFi settings to get Internet access and b) has to be ‘claimed’ – in other words, associated with our developer’s account so that we (and no-one else) can access the board remotely virtually from any place on Earth (provided that the place has Internet connection). Unfortunately, programming a device with correct WiFi setting is not enough. Nowdays many WiFi networks have MAC address filtering in place which basically means that MAC address must be manually specified on WiFi access point. But the thing is that there is no easy way to get Spark core’s MAC address! It is labeled nether on the kit’s box, nor on the board or WiFi module. Then the next logical step would be to connect the board to a PC via USB cable and interrogate it to get MAC address, right? No! The command line interface is really ascetic – it only allows to set WiFi SSID and password and read core’s unique identifier (also known as core id), nothing more. Well… maybe core id contains MAC address then? To answer this question we downloaded source code for spark’s firmware and after analysing it discovered that core id is actually a unique microprocessor id and has nothing to do with WiFi MAC address which brought us back to square one leaving with the same question: how to get Spark core’s MAC address?

Turning our attention to the Internet we realised that people were suffering from the same problem. Here is a discussion about extracting MAC address by running a sketch. The funny part is that in order to upload sketch to the core, it has to be already claimed. And in order to be claimed it must have an Internet access already! So really it all comes down to disabling MAC address filtering on your WiFi access point, claiming the core, programming it with the sketch that extracts the MAC address and after that adding the newly discovered MAC address to the list of permitted devices on WiFi access point and only then enabling MAC address filtering again. Why it should be done in such a clumsy way – it is really a question to Spark core developers, all this could be easily simplified by just adding one extra command to Spark’s command line interface which would retrieve MAC address. As simple as that.

Spark IO Unpacked

Spark IO Unpacked

But in the end the problem with configuring was the only thing that we really didn’t like. The core has been eventually claimed and we felt tremendous freedom and flexibility provided by the solution.

Spark Core Successfully Configured

Spark Core Successfully Configured

Of course, as any product is has its own pros and cons and here is the list below that we came up with:

Advantages:
- It is Arduino compatible. Sketches and libraries designed for Adruino can be used for Sketch IO designs with zero or minimum modifications;
- It is fast. Ridiculously fast comparing to Arduino;
- It has really small form factor;
- It comes with API for cloud, iPhone and Android OS integration. All cloud-Spark core, cloud-userapp communications are secure;
- It is probably the cheapest WiFi-powered kit of that kind at the moment;
- Online development environment, zero effort to install and configure (it is also a disadvantage by the way :) );

Disadvantages:
- There is obviously no backward compatibility with Arduino;
- Number of GPIOs is less than, let’s say’ in case of Arduino Uno;
- Difficulties with getting MAC address which complicates initial configuring process;
- Not widely available at the moment. The only place to buy is SparkIO itself;
- Online development environment, your source code is kept somewhere is the cloud out of your control and potentially available for everyone if anything;

Mini Maker Faire 2014

Just recently we had an opportunity to participate in Sydney’s Mini Maker Faire 2014. This was the second event of a kind being organised at Powerhouse Museum in Sydney. The decision to take part has been made spontaneously and one only week before ‘the day’ which, to some extent, contributed to our poor performance and lack of interest to our project but also highlighted things that must be done in order to stand out of the crowd and get noticed by people.

As a result of a pure accident we have been invited by Solidifier community to present at The Faire a DIY electronic project as part and on behalf of community’s movement. Willing to demonstrate Luminardo board we met with Solidifier guys and after a little bit of discussion decided to ‘make it more interactive’. In other words, Luminardo board would have to work in tandem with basic Android phone via Bluetooth interface. While the required Luminardo’s functionality was virtually a matter of putting all the libraries and examples together Android side was nonexistent (including both application and phone itself). We rushed to a closest mobile phone shop, picked up a budget model and spent remaining time developing and debugging Android application – all was done within the next week so the project was ready to go. What has been eventually presented is compiled in the video below. The phone acts as a remote control, allowing selection of different modes and special effects on Luminardo board. The most effective thing is probably a color picker when a particular color preselected on the phone is immediately displayed by RGB LED on the board.

While the overall experience is considered to be useful we still incline to think that this event was a ‘successful failure’ for our project. Successful because of being part of this amazing community and event, because of friendly and dedicated people that we had honor to meet. Failure because our project remained virtually noticed by no one. And it wasn’t just by chance, there were reasons for that. So, after careful consideration we have came up with a list of things that would have to be done differently when we decide to take part in an event of this type, some of the reasons are really obvious, however, it didn’t prevent us from overlooking them:

  • Make sure you start working on a project well in advance before the actual event;
  • Design a project specifically for the event you going to take part in instead of tailoring already existing project;
  • It is really good to have a finished thing with a specific function instead of a generic platform which can do a lot but doesn’t exhibit any practical application;
  • Think how to attract visitor’s attention – in case of Mini Maker Faire projects glowing with LEDs brighter and moving fast were in essence in advantageous position;
  • Make sure that you present your project by yourself. That is true, other designers only care about their own things, no one else can demonstrate your project better than you;
  • If it is possible, try to register as independent participant, not as a member of some group – in the end, any group’s primary intention is to promote itself, not your project;

But on a positive note, we really enjoyed the atmosphere of the Maker Faire and were pleased to see many familiar faces, look at really cool projects and people who definitely like making things.

We also would like to express our gratitude to Andrew Stone and James Zaki for organising the process and taking our project onboard.

Downloads:

1. A snapshot of Luminardo core files for Arduino IDE;

2. A snapshot of library for MVFD Panel 16S8D;

3. A snapshot of USB Host 2.0 library tweaked for Luminardo;

4. Luminardo Bluetooth Remote Control sketch;

5. Luminardo Bluetooth Control Android App.

Quiz System DIY Arduino Project for a Budget Price

This time our task was to build a Quiz System (also known as ‘Quiz Buzzer’ or ‘Quiz Show’). The real challenge was in meeting two major requirements: being really inexpensive and looking attractive and ‘factory-made’ at the same time as the project was intended for use in elementary school. To our surprise, it became almost next to impossible: when it comes to a pushbutton combined with a bulb or a LED, large enough to be pushed with a palm the price climbs unjustifiably high even for a single button. Given that our project was envisaged to be used by up to six participants the overall cost per unit looked really bleak. And vice versa, cheap (or at least affordable) buttons available at online electronic shops looked too simple or even ugly. That is why we turned our attention to doorbells hoping to find big and reliable buttons. Again, without any success as there is a tendency to shift to wireless doorbells because apparently selling just plain buttons is not a profitable business anymore. We began wandering around visiting numerous local shops looking for something that could work as a pushbutton. And all of a sudden a battery powered wall light in a Chinese shop caught our attention – it looked like a button but at the same time it had a round dome which was illuminated by a bulb just like we needed! But most importantly it had a price tag of just $2! The only problem was that it acted as ‘push and hold’ instead of just ‘push’. In other words, first push switches the light on and in order to switch the light off it has to be pushed again. We decided to take a risk and bought one light to see whether is was possible to convert it to a ‘pushbutton’. As it turned out it was an easy task to do the modification so we rushed and got five more as it is shown on the picture below.

Round Lights From Chinese Shop

Round Lights From Chinese Shop

And then it was just a matter of replacing bulbs with LEDs and wiring buttons and LEDs to Arduino board. The table below shows the total cost of materials and parts under $47 which is pretty good as the initial requirement was to stay just below $100. Besides, there are still ways to bring down the total cost even more.

Part Supplier Unit Price, A$ Count Extended Price, A$
Arduino Mega2560 R3 Aliexpress/Ebay
13.00
1
13.00
Mega Enclosure – Blue (PRT-11985) Sparkfun
12.95
1
12.95
Push button (modified wall light) Local Chinese shop
2.00
6
12.00
Huckup Wire Pack (WH3025) Jaycar Electronics
4.95
1
4.95
1.5mm Heatshrink Tubing (WH5570) Jaycar Electronics
1.45
1
1.45
Red/Orange/Green/Blue Through Hole 3mm LED >=2700 mcd Digikey Electronis
0.31
6
1.86
Through Hole 180 Ohm Resistor 0.125W Digikey Electronis
0.09
6
0.54
Total
46.75

LEDs and buttons wiring up is rather asсetic and doesn’t require advanced soldering skills. LEDs are connected as common cathode so they share common ground with buttons. Each pushbutton needs three wires, one for button, one for LEDs and one for ground. The given example uses Arduino Mega2560 w which is a little bit overkill for this project and technically speaking virtually any other Arduino board can be used with minimum changes to the wiring up.

Quiz System Wiring Up

Quiz System Wiring Up

The Arduino sketch provided below shows that the application is really simple: it initialises 6 pins in PWM mode to control LEDs and 6 pins in input mode to read button states. Any change on button inputs triggers an interrupt so that it allows to handle all six buttons independently and without priorities, all users are given equal opportunities. Upon bootup the system enters demo mode when all buttons are lit up sequentially and any button press toggles the gaming mode. In gaming mode a system first waits for a button press. Button which happens to be hit first is illuminated for a few second and the the system is ready for the next round.

/*
 QuizSystem.c - automated quiz system for six participants 

 Copyright (c) 2014 Dmitry Pakhomenko.
 dmitryp@magictale.com

http://magictale.com

 This code is in the public domain.
*/

#define BTN_1 62	//PK0 PCINT16
#define BTN_2 63	//PK1 PCINT17
#define BTN_3 64	//PK2 PCINT18
#define BTN_4 65	//PK3 PCINT19
#define BTN_5 66	//PK4 PCINT20
#define BTN_6 67	//PK5 PCINT21

#define LED_1 8
#define LED_2 9
#define LED_3 10
#define LED_4 11
#define LED_5 12
#define LED_6 13

const char PRODUCT_NAME[] PROGMEM = "QuizSystem";
const char SPACE_CHAR[] PROGMEM = " ";
const char FIRMWARE_REV[] PROGMEM = "V1.0";
const char FIRMWARE_DATE[] PROGMEM = "22.07.14";
const char COMPANY_URL[] PROGMEM = "http://magictale.com";
const char BTN_PREFIX[] PROGMEM = "BTN: ";
const char INITIAL_STATE[] PROGMEM = "INITIAL STATE";

#define MAIN_LOOP_DELAY 2000
#define SECONDS_IN_SHOWING_RESULTS_STATE 5 * 5 //ToDo: not really in seconds at the moment...

enum enum_SysState
{
    sysSelfTest,
    sysInitial,
    sysQuiz,
    sysShowResult,
    sysFailure
};

volatile uint8_t sysState;        //current system state (mode)
volatile uint8_t initStateTimer;  //seconds remaining before going to back to initial state
volatile uint8_t btnTriggered;    //flag indicates that a button press was detected
volatile uint8_t btnReg;          //button register;
volatile uint8_t testState;

void serialEvent()
{
    while (Serial.available() > 0)
    {
        //dump the received byte for now
        Serial.read();
    }
}

void initLEDs()
{
    analogWrite(LED_1, 0);
    analogWrite(LED_2, 0);    
    analogWrite(LED_3, 0);    
    analogWrite(LED_4, 0);    
    analogWrite(LED_5, 0);    
    analogWrite(LED_6, 0);    
}

void setup() 
{ 
    analogReference(DEFAULT);  
    
    //Set up 6 button inputs with pullup resistors
    pinMode(BTN_1, INPUT_PULLUP);
    pinMode(BTN_2, INPUT_PULLUP);
    pinMode(BTN_3, INPUT_PULLUP);
    pinMode(BTN_4, INPUT_PULLUP);
    pinMode(BTN_5, INPUT_PULLUP);
    pinMode(BTN_6, INPUT_PULLUP);
    
    //Enable interrupts for buttons
    PCICR |= _BV(PCIE2);
    PCMSK2 |= _BV(PCINT16);    
    PCMSK2 |= _BV(PCINT17);    
    PCMSK2 |= _BV(PCINT18);
    PCMSK2 |= _BV(PCINT19);    
    PCMSK2 |= _BV(PCINT20);    
    PCMSK2 |= _BV(PCINT21);
    
    pinMode(LED_1, OUTPUT);
    pinMode(LED_2, OUTPUT);
    pinMode(LED_3, OUTPUT);
    pinMode(LED_4, OUTPUT);
    pinMode(LED_5, OUTPUT);
    pinMode(LED_6, OUTPUT);
   
    initLEDs();

    sysState = sysSelfTest;

    Serial.begin(57600);

    Serial.print(reinterpret_cast<const __FlashStringHelper *>(PRODUCT_NAME));
    Serial.print(reinterpret_cast<const __FlashStringHelper *>(SPACE_CHAR));
    Serial.print(reinterpret_cast<const __FlashStringHelper *>(FIRMWARE_REV));
    Serial.print(reinterpret_cast<const __FlashStringHelper *>(SPACE_CHAR));
    Serial.println(reinterpret_cast<const __FlashStringHelper *>(FIRMWARE_DATE));
    Serial.println(reinterpret_cast<const __FlashStringHelper *>(COMPANY_URL));

    initStateTimer = 0;
    btnTriggered = false;
    testState = 0;
}

void handleBtnPress()
{
    Serial.print(reinterpret_cast<const __FlashStringHelper *>(BTN_PREFIX));
    Serial.println(btnReg, BIN);

    if ((btnReg) & 0x1) digitalWrite(LED_6, HIGH);
    else if ((btnReg >> 1) & 0x1) digitalWrite(LED_5, HIGH);
    else if ((btnReg >> 2) & 0x1) digitalWrite(LED_4, HIGH);
    else if ((btnReg >> 3) & 0x1) digitalWrite(LED_3, HIGH);
    else if ((btnReg >> 4) & 0x1) digitalWrite(LED_2, HIGH);
    else if ((btnReg >> 5) & 0x1) digitalWrite(LED_1, HIGH);
}

void demo()
{
    while (1)
    {
      for (uint8_t pwm = 0; pwm < 255; pwm++)
      {
          initLEDs();
          
          if (testState == 0) analogWrite(LED_1, pwm);
          else if (testState == 1) analogWrite(LED_2, pwm);
          else if (testState == 2) analogWrite(LED_3, pwm);      
          else if (testState == 3) analogWrite(LED_4, pwm);      
          else if (testState == 4) analogWrite(LED_5, pwm);
          else if (testState == 5) analogWrite(LED_6, pwm);      
          else if (testState == 6) 
          {
            analogWrite(LED_1, pwm);
            analogWrite(LED_2, pwm);        
            analogWrite(LED_3, pwm);        
            analogWrite(LED_4, pwm);        
            analogWrite(LED_5, pwm);        
            analogWrite(LED_6, pwm);        
          }
          delay(1);
      }
      
      for (uint8_t pwm = 255; pwm > 0; pwm--)
      {
          initLEDs();
          
          if (testState == 0) analogWrite(LED_1, pwm);
          else if (testState == 1) analogWrite(LED_2, pwm);
          else if (testState == 2) analogWrite(LED_3, pwm);      
          else if (testState == 3) analogWrite(LED_4, pwm);      
          else if (testState == 4) analogWrite(LED_5, pwm);
          else if (testState == 5) analogWrite(LED_6, pwm);      
          else if (testState == 6) 
          {
            analogWrite(LED_1, pwm);
            analogWrite(LED_2, pwm);        
            analogWrite(LED_3, pwm);        
            analogWrite(LED_4, pwm);        
            analogWrite(LED_5, pwm);        
            analogWrite(LED_6, pwm);        
          }
          delay(1);
      }
      
      testState++;
      if (testState > 6) 
      {
          testState = 0;
          break;
      }
    }
}

void loop()
{
    if (millis() % MAIN_LOOP_DELAY == 0)
    {
        if (initStateTimer != 0) initStateTimer--;          
    }
  
    switch (sysState)
    {
        case sysSelfTest:
        {
            demo();          
            break;
        }
        
        case sysQuiz:
        {
          
            break;  
        }
        
        case sysShowResult:
        {
       
            if (btnTriggered)
            {
                handleBtnPress();                            
                btnTriggered = false;
            }

            if (initStateTimer == 0)
            {
                sysState = sysQuiz;
                initLEDs();
                Serial.println(reinterpret_cast<const __FlashStringHelper *>(INITIAL_STATE));
            
            }
        }
        break;
       
        
        default:
            ;
        
    }
}

ISR(PCINT2_vect)
{
    cli();
    
    btnReg = 0x7F & ~*portInputRegister(digitalPinToPort(BTN_1));    
    
    if (sysState == sysQuiz)
    {
        sysState = sysShowResult;
        initStateTimer = SECONDS_IN_SHOWING_RESULTS_STATE;
        btnTriggered = true;
       
    }else if (sysState == sysSelfTest)
    {
        sysState = sysQuiz;      
        initLEDs();
    }
    sei();
}

The video below shows the process of building and Quiz System in action:

What is more important, the system has plenty of resources unused and this project can be looked at as a template for more advanced and sophisticated designs. For example, it can be integrated with a PC via USB interface so that the device can control Power Point presentations for instance which would navigate to certain pages depending on user input. Another possible enhancement is addition of a RC interface for master control or a small graphic display to indicate winner number – all those small things which would make children interested in gaming process or maybe even in electronics & programming.

Envisaging Case for Luminardo

Recently we have been busy working on new stylish case for Luminardo project. The challenge is to design something which would cost reasonable price and at the same time have modern look. Making cases of acrylic panels by laser cutting them is relatively inexpensive but all cases look kinda the same – like ugly boxes. On the other hand, 3D-printed parts may potentially have any shape but this technique is still rather expensive. In addition, it is very problematic to make 3D printed surface as shiny and polished as acrylic panels. Besides, it is impossible to mare transparent 3D-printed parts. But what if we combine acrylic and 3D-printed elements in one assembly? The we still should be able achieve stylish look and bring down the overall cost. There are the following prerequisites for this particular project:

a) Front panel has to be transparent (or as a minimum has to have a viewport). This is required not only by the VFD display itself but by light sensor, IR receiver and RGB LED;

b) Rear panel need to have multiple cut offs for numerous connectors (by the way, most of them are optional). The panel can be opaque but having it made of acrylic would let us achieve more dramatic look;

c) As a whole the outer shell should look… streamlined if it is possible to say. Like a pebble.

And here is what we have come up with. Variant “1″ is shown below. The shell is visibly bigger than the PCBAs and therefore requires more material. At the same time, it looks like all the prerequisites are taken care of.

Luminardo Case Experiment Front View

Luminardo Case Experiment Front View

Luminardo Case Experiment Bottom View

Luminardo Case Experiment Bottom View

Luminardo Case Experiment Rear ISO View

Luminardo Case Experiment Rear ISO View

Luminardo Case Experiment Bottom ISO View

Luminardo Case Experiment Bottom ISO View

Luminardo Case Experiment Front ISO View

Luminardo Case Experiment Front ISO View

Luminardo Case Experiment Exploded View

Luminardo Case Experiment Exploded View

Variant “2″ is shown below. It uses an acrylic inset which works like a feet and as an element of design – it glows as it is illuminated by the RGB LED. On the other end of the case there are two small feet which gives the unit asymmetric and unusual look. However, it is not clear whether the IR receiver would be able to work through the thickness of the inset. And the VFD viewport must extent more to the left in order for the light sensor to be functional.

Luminardo Case Experiment Front View

Luminardo Case Experiment Front View

Luminardo Case Experiment Bottom View

Luminardo Case Experiment Bottom View

Luminardo Case Experiment Rear ISO View

Luminardo Case Experiment Rear ISO View

Luminardo Case Experiment Bottomt ISO View

Luminardo Case Experiment Bottomt ISO View

Luminardo Case Experiment Front ISO View

Luminardo Case Experiment Front ISO View

All in all, it is still work in progress. We are waiting for comments and more ideas!

Downloads:

1. Case for Luminardo in SketchUp, experiment “1″

2. Case for Luminardo in SketchUp, experiment “2″

Case for Pilot Display

It is time to put our Pilot Display into a case. A box of appropriate size and shape has been found at Blacktown’s Jaycar store. The dimensions were almost ideal with only one problem – a battery compartment that prevented PCBA from fitting inside. It tuned out not to be a problem for us, using some files we successfully cut off the compartment. With the help of a miniature drill holes on the front panel were made. In order to secure the board inside nylon standoffs have been glued with a glue gun. The board is mechanically secured with two screws. A battery compartment lid conveniently provides access to board’s edge and USB connectors.

Pilot Display Case Modified

Pilot Display Case Modified

Pilot Display Board Fitted In Case

Pilot Display Board Fitted In Case

Pilot Display Fully Assembled Back Lid Off

Pilot Display Fully Assembled Back Lid Off

Pilot Display Fully Assembled

Pilot Display Fully Assembled

Firmware for Pilot Display

The firmware of Pilot Display unit comprises of two parts: bootloader and main application. Bootloader simplifies the process of main application upgrade – once the bootloader is programmed, there is no need in external programmers to do firmware upgrades. Source code of the main application is designed as a sketch for very popular Arduino platform which appeals for its rapid prototyping approach and extremely short induction time when a new member joins to a project or when it comes to knowledge transfer between a contractor and a customer. Currently Arduino IDE doesn’t have official support for ATMega1281P microprocessor but that support can be easily added to the environment. For more details about initial Arduino IDE setup please refer to this link.

The main application has three modes: test mode, configuration mode and normal mode. Test mode is initiated automatically immediately after reboot upon applying power to the unit. There is a few seconds delay after start as initially control is given to the bootloader. The bootloader has a timeout of a few seconds during which it is waiting on activity from serial port. If no requests to perform firmware updates is received then the bootloader launches the main application. Main application initialises LED drivers and switches LEDs one by one until all of the are lit up. Then all LEDs are switched off and the unit enters normal mode. At this point the unit is ready to receive commands from turbine engine ECUs.

Configuration mode is intended for changing unit’s default parameters such as baudrate for both serial ports and current through LEDs. By changing the current flowing through LEDs brightness adjustment is achieved. Brightness for red, green and orange colors is adjusted individually. To enter configuration mode disconnect ‘LEFT ENGINE’ serial port from ECU, connect it to a PC/laptop, run a terminal app like ‘Hyperterminal’ with baudrate set to 2400 bps and type ‘aaaaaa’. The unit should respond with the list of available commands and current settings. Follow the instructions to configure the unit.

The video below shows display’s LED test in progress:

Downloads:

1. Turbine ECU communication protocol V2.14-Vx.35 by AMT Netherlands

2. Pilot Display Bootloader Rev.1.0

3. Pilot Display Production Firmware (Arduino Sketch) Rev.1.0

First Pilot Display PCB is Assembled

First Pilot Display PCB is finally assembled and tested. As it usually happens with revisions 1.0 there are several things that have been overlooked during design. Good news is that all issues are minor and don’t impact main functionality. Here are the discovered issues:

a) First of all, FT232 is not powered when USB cable is not connected resulting TXLED and RXLED outputs being pulled low and as a consequence LD1 and LD2 are constantly switched on. Connecting USB cable puts both LEDs to the desired (switched off) states even when the cable is then unplugged. This is annoying but given that both LEDs are powered with 1K resistors in series, it doesn’t make much of a difference in power consumption even with both LEDs being permanently switched on.

b) The next problem though is ST3232BSOIC16 which shares RX-I and TX-O signals with FT232. ST3232BSOIC16 never puts its outputs into hi-z state and therefore microprocessor ATMEGA1284PA can’t receive data from FT232 which is essence means that USB interface cannot be used for firmware updates, maximum that we can get is a debug output through USB. However, firmware updates still can be done via RS232 interface for the left engine (TX_LEFT and RX_LEFT). In the next revision it will be worth adding a jumper to manually switch between serial and USB interfaces;

c) R5 resistor doesn’t make much sense and better to be replaced with 0.1uF ceramic capacitor;

d) Both MAX6957 are not designed to put their DOUT outputs into hi-z mode when not selected by SS which creates conflicts on the SPI bus when the microprocessor is being programmed via ISP header. We managed to program the microprocessor by cranking up VCC to 5V via ISP header. Once the bootloader is programmed, there is no need in ISP anymore as from that point the firmware can be updated via RS232 interface without need to use external ISP programmer;

e) Really strange and unexpected issue – red LEDs are slightly bigger than green and orange ones despite they all are of the same form factor. Attempts to find another type of red LEDs resulted in the same slightly bigger sizes!

f) LEDs are really difficult to solder precisely so it would be worth using LED spacers for the next boards;

g) At the end of this design cycle the customer expressed a desire to have opto-isolation for both RS232 ports so looks like that ST3232BSOIC16 would need to be replaced with something else;

The DC-DC converter is capable of delivery up to 1A @ 3V3 and was successfully tested under maximum load by switching all LEDs simultaneously at maximum current of 20mA per LED. No excessive power dissipation is under maximum load – all chips remain cold when touching with a finger.

Fully assembled board is shown on the pictures below.

Pilot Display PCBA Bottom

Pilot Display PCBA Bottom

Pilot Display PCBA Top

Pilot Display PCBA Top

Pilot Display PCBs arrived

Pilot Display Rev.1.0 PCBs finally arrived. At a first glance nothing is terribly wrong, everything seems to be fine which is a good start. However, there is always something in rev1.0 boards or schematics so will see what the subsequent assembling process and preliminary test bring us. As always, Itead Studio PCB manufacturing service has been used, they made and shipped 6 PCBs instead of promised 5.

This is what the PCBs look like:

Pilot Display bare PCBs

Pilot Display bare PCBs

Wait for more upcoming updates on this project.

Pilot Display for… a Twin Turbine Engine!

Just recently by a pure accident we became involved into very unusual project. Willing to become known to some degree amongst the local Sydney electronics enthusiasts we decided to take part in one of the community projects and help to build something. It didn’t take much time to wait for someone who posted a request asking for assistance to design a LED display panel for engine health status indication. At a first glance it looked like a toy for a remotely controlled plane equipped with a miniature turbine engine. However, it soon turned out to be more serious: the panel was supposed to indicate health status of a full scale twin turbine engine being part of a personal turbine powered aircraft! Display was required to show RPM and temperature for both engines individually and ‘flight time’. All information was requested to be represented by columns of super bright LEDs, the solution would have to be be power efficient, receive data streams from both ECUs (Engine Control Units) via regular RS232 ports, have a capability of firmware update and work in wide range of input voltages (with the efficiency peak somewhere in 15…16V range as it is a typical voltage of the aircraft’s onboard lithium battery).

After doing some preliminary experiments with multiplexed displaying technique we got unsatisfactory results for LED brightness under direct sunlight and decided to go for static indication by using specialised MAX6957 chips which also allow controlling current flowing through each individual LED and therefore allow for programmatically adjustable brightness. On top of that we decided to use USB to serial converter for easier firmware updates/debugging and a photo resistor acting as a light sensor. And here is the result of our effort.

The circuit diagram of the display panel is given below.

Pilot Display CircuitDiagram Rev.1.0

Pilot Display CircuitDiagram Rev.1.0

The PCB layout is done on two layers. Component placement for top and bottom sides are given on the pictures below.

PilotDisplay Component Layout Rev1.0

PilotDisplay Component Layout Rev1.0

A 3D model of the PCBA and Sketchup snapshots are given below.

Pilot Display PCBA 3DModel Top View

Pilot Display PCBA 3DModel Top View

Pilot Display PCBA 3DModel Top ISO View

Pilot Display PCBA 3DModel Top ISO View

Pilot Display PCBA 3DModel Bottom ISO View

Pilot Display PCBA 3DModel Bottom ISO View

Pilot Display PCBA 3DModel Side View

Pilot Display PCBA 3DModel Side View

Downloads:

1. Pilot Display Gerber files Rev1.0

2. Pilot Display Eagle files Rev1.0

3. Pilot Display SketchUp 3D Model Rev1.0

4. Pilot Display Component 3D Models

4. Pilot Display BOM (Bill Of Materials)

Firmware source code is yet to come – stay tuned.

Bluetooth for Dummies: Domesticating RFComm

Knowing RFComm port number to connect to we are fully set for our final step – to establish RFComm communication channel. Before we can send RFComm specific commands we need to establish L2CAP connection to RFComm the same way as it has been already described in ‘Establishing connection to SDP’. The only difference is that this time we need to use RFComm PSM (0×03) rather than SDP PSM. Let’s not focus our attention on L2CAP as it is now a technicality of no interest and shift our attention to RFComm specifics.

Make the same preparations and run two consoles with logging hcpdump applications and it was described in this post. Let’s analyze packet exchange immediately after establishing connection to RFComm. Here is what the first console would typically report:

< ACL data: handle 43 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c //1-st SABM command
> ACL data: handle 43 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7 //UA response

< ACL data: handle 43 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8 //PM (paramater negotiation) request
dlci 32 frame_type 0 credit_flow 15 pri 7 ack_timer 0
frame_size 55 max_retrans 0 credits 7
> ACL data: handle 43 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8 //PM (parameter negotiation) response
dlci 32 frame_type 0 credit_flow 14 pri 0 ack_timer 0
frame_size 55 max_retrans 0 credits 7

< ACL data: handle 43 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 32 pf 1 ilen 0 fcs 0xca //2-nd SAMB command
> ACL data: handle 43 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 32 pf 1 ilen 0 fcs 0x1 //UA response

< ACL data: handle 43 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2 //MSC (modem status) command
dlci 32 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> ACL data: handle 43 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2 //MSC (modem status) command
dlci 32 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0

< ACL data: handle 43 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2 //MSC (modem status) response
dlci 32 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> ACL data: handle 43 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2 //MSC (mode status) response
dlci 32 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0

< ACL data: handle 43 flags 0x02 dlen 9
L2CAP(d): cid 0x0041 len 5 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 32 pf 1 ilen 0 fcs 0xc4 credits 33 //Command with credit

Let’s have a look at the same exchange in raw representation logged by the second console and try to decode it:

< 0000: 02 2a 20 08 00 04 00 41  00 03 3f 01 1c           .* ....A..?.. //1-st SABM on channel 0 (byte @ 0x9 == 0x3)
> 0000: 02 2a 20 08 00 04 00 41  00 03 73 01 d7           .* ....A..s.. //UA response

< 0000: 02 2a 20 12 00 0e 00 41  00 03 ef 15 83 11 20 f0  .* ....A...... . //PM (paramater negotiation) request
0010: 07 00 37 00 00 07 70                              ..7...p
> 0000: 02 2a 20 12 00 0e 00 41  00 01 ef 15 81 11 20 e0  .* ....A...... . //PM (parameter negotiation) response
0010: 00 00 37 00 00 07 aa                              ..7....

< 0000: 02 2a 20 08 00 04 00 41  00 83 3f 01 ca           .* ....A..?.. //2-nd SABM  on channel 0x10 (byte @ 0x9 == 0x83, channel number << 3 = 0x80)
> 0000: 02 2a 20 08 00 04 00 41  00 83 73 01 01           .* ....A..s.. //UA response

< 0000: 02 2a 20 0c 00 08 00 41  00 03 ef 09 e3 05 83 8d  .* ....A........ //MSC (modem status) command
0010: 70                                                p
> 0000: 02 2a 20 0c 00 08 00 41  00 01 ef 09 e3 05 83 8d  .* ....A........ //MSC (modem status) command
0010: aa                                                .
< 0000: 02 2a 20 0c 00 08 00 41  00 03 ef 09 e1 05 83 8d  .* ....A........ //MSC (modem status) response
0010: 70                                                p
> 0000: 02 2a 20 0c 00 08 00 41  00 01 ef 09 e1 05 83 8d  .* ....A........ //MSC (modem status) response
0010: aa                                                .

< 0000: 02 2a 20 09 00 05 00 41  00 83 ff 01 21 c4        .* ....A....!. //Command with credit on channel 0x10

...and... rock'n'roll!

Time to put everything together. Get source code from Download section below, update your installation of USB Host 2.0 library on your machine, run the provided sketch making sure that ELM327 is powered and within range of your Luminardo board. You should see something similar to the output provided below. Note, that very last reply >LM327 v1.5 is transmitted by ELM327 which means that we have established SPP communication channel! The only remaining part now is to put logic which communicates with ELM327 and renders received values on VFD panel.

Luminardo USB Host Bluetooth SPP Test
SPP Bluetooth Library Started
Enabling VBus... enabled
Bluetooth Dongle Initialized
HCI Reset complete
Write class of device
Local Bluetooth Address: 00:19:0E:12:65:6A
The name is set to: Luminardo
Pairing to 'Other' device with predefined address
Device: 40:22:11:00:69:58 has been found
Connecting to 'Other' device...
Connected to 'Other' device
Received Key Request
Bluetooth pin is set too: 1234
Pairing successful with 'Other' device
SDP Connection Request Sent
L2CAP Connection Response
SDP Connection Response
SDP Configuration Request Received
SDP Configuration Response Sent
SDP Configuration Request Sent
SDP Configuration Response Received
SDP Successfully Configured
SDP Service Search Attribute Request 1 Sent
Channel will be in the next packet
SDP Service Search Attribute Request 2 Sent
Channel found in second packet: 16
RFComm Connection Request Sent
L2CAP Connection Response
RFComm Connection Response
RFComm Configuration Request Received
RFComm Configuration Response Sent
RFComm Configuration Request Sent
RFComm Configuration Response Received
RFComm Successfully Configured
RFComm SABM Sent
Received UA RFComm Packet on channel: 00
Sent UAH RFComm Cmd BT_RFCOMM_PN_CMD (Parameter Negotiation Request) on channel: 00
Received UIH RFComm Packet on channel: 00 - BT_RFCOMM_PN_RSP (Parameter Negotiation Response)
RFComm 2-nd SABM Sent
Received UA RFComm Packet on channel: 10
Send UIH RFComm Cmd BT_RFCOMM_MSC_CMD (Modem Status Command)
Received UIH RFComm Packet on channel: 00 - BT_RFCOMM_MSC_CMD (Modem Status Cmd)
Send UIH RFComm Cmd BT_RFCOMM_MSC_RSP (Modem Status Response)
Received UIH RFComm Packet on channel: 00 - BT_RFCOMM_MSC_RSP (Modem Status Response)
RFComm Cmd with Credit Sent
Serial Bluetooth connected

>LM327 v1.5

Now the implemented functionality allows to establish SPP communication between two Arduino boards equipped with USB Host shields. It is also quite remarkable that this particular Bluetooth dongle is not functional under WinXP because it comes with Win8 driver only yet our hardware happily communicates with the dongle!

Downloads:

1. USB Host 2.0 For Arduino – Bluetooth SPPi addon;

2. UPDATE 2014.09.28: Full snapshot of USB Host 2.0 For Arduino with Bluetooth SPPi addon;