This article was prepared back in October 2013 but remained unpublished all these months. At first, when we got Arducam Rev.C in possession its rich set of features and performance inspired us greatly. However, just within a few days the interested moved on, became dim and then quickly faded away. It simply turned out that despite all advantages there were as much limitations. Flicking through the list of unpublished posts we decided to review the article and give it another go. But enough of foreword, here is the article itself.
Necessity of taking pictures by means of an embedded platform is not new. The problem existed for a while as it was (and still is) very resource demanding in spite of tremendous advances in embedded computing last years. The problem is aggravated by the fact that people are getting used to better picture quality as technology evolves so solutions that had reasonable performance and image resolution couple of years ago are not acceptable anymore. It has been always a trade off between picture quality and hardware non-overcomplication. In other words, for cheap and inexpensive 8-bit Arduino-like host controller during last few years there was not that much to choose from: a serial enabled VGA camera module C328 replaced with uCam and LinkSprite. Both have been recently discontinued as they couldn’t offer resolution greater than VGA while having a price tag at around $50. The only alternative to the abovementioned VGA camera modules was an opensource project called Hacrocam. With a single advantage of being opensource Hacrocam had the same set of flows: same low resolution (VGA), only one image sensor type supported and similar price tag (around $40). No wonder that the project couldn’t live long life – and as for today, October 2013, the item is marked as ‘sold out’ at Hacrocam’s site.
Unlike camera modules ArduCam didn’t have much of public attention or appreciation and was silently evolving for a while. It’s first revision used LCD’s RAM as a frame buffer and therefore was limited in resolution even more than the modules. But ArduCam engineers kept working and finally Rev. B and then Rev.C came to existence. Even from a first glance it becomes obvious that this solution is superior in comparison with the abovementioned solutions. ArduCam Rev.C didn’t use any particular image sensor, instead, it supported concept of interchangeable sensors and at that time was capable of working with sensors up to 5MP. The quality of pictures and resolution was much better when comparing with products from the same ‘lightweight’ class. The Arducam board was controlled by I2C interface making it simple and easy to use. However, despite all reassurances from Arducam developers, it is NOT opensource project and it can’t be. The source code for FPGA chip is kept private and as for the design files, only Rev. B schematics is available, nothing for Rev. C and nothing for PCB design. This puts this project in the same category with countless proprietary things, as simple as that. All our questions to developers as to why this project is considered as ‘open hardware’ when there is no public access to design files – all these questions have been just silently ignored.
Nevertheless, let’s have a look at the Arducam board and do a test driver. As it turned out, the board didn’t quite mate with Arduino Mega that has been in our lab – it was a bit old and didn’t have I2C pins at right location. We did a workaround as it is shown on the picture below.
Arducam Rev. C and Arduino Mega
The final assembly looks bulky and it is not possible for a sensor to revolve or tilt unless the whole assembly is repositioned. And even being so bulky, the solution still lacks transport module of some kind to be able to upload data wirelessly to a server not to mention that it would be a big question on how to connect such a module as there is no convenient USB host interface or similar available.
Arducam Rev. C assembled
Arducam Rev. C assembled Rear View
A typical picture taken in daylight conditions without tripod is given below. The picture is a bit blurry but still reasonably good for a custom made camera with fixed lens and iris.
ArduCam 3MP Sensor Test
However, the picture is visibly noisy in dark regions and it has a little bit of fish eye distortion. On the other hand, the the size is only 107 Kbytes which is pretty good as it is easy to handle by basic embedded systems like Arduino.
To sum up, let’s give a synopsis on what we discovered:
- The idea and functional implementation are great but PCB’s form factor and closed source code along with design files kill both the idea and functionality making it impossible to adapt the project to something different from Arduino;
- Without design files available to the community there won’t be support for new image sensors so the project will decease as soon as Arducam guys shift their focus to something else when they won’t have enough resources to maintain this project;
- It is a big challenge to communicate with Arducam developers, those guys rather prefer to ignore your requests and comments unless they are in ‘guys_you_are_great’ style.
The need in inexpensive, simple and compact power supply unit (PSU) for VFD projects has always been topical for us. MVFD 16S8D Panel was designed to address the challenge, however, as it always the case for first revision, there are some things which require improvements or rethinking. And MVFD Panel was not an exception in this sense. Let’s quickly highlight requirements for PSU:
- Single (5V) input voltage with filament and segment/grid voltages being generated internally;
- No transformers or custom winded ferrites;
- Pulse filament drive to avoid brightness gradient;
- Feedback for segment/grid high voltage to break dependency between brightness and number of illuminated segments;
- Shutdown mode;
- Overcurrent protection is highly desirable;
- Filament/segment voltages to be adjustable in reasonable range to make the solution as generic as possible in order to support more than just one type of VFD;
- Reasonable number of components, compact dimensions;
- High availability of components with no ‘end of life’ or ‘not recommended for new design’ things;
- All components must be handsolderable;
- The total cost of components should not be greater than $5-6;
On the other hand, the previous design had the following issues:
- LM9022 filament driver became obsolete;
- Segment/grid voltage was generated by a charge pump using pulse filament drive and making segment and filament voltages interdependent on each other leaving without possibility of fine tuning;
- Absence of feedback for segment voltage caused less segments to shine brighter and more segments to be dimmed;
- Five stages of charge pump require substantial area on PCB;
So in our next PSU revision we will aim to address most (if not all) issues of the prior design. After countless hours of search we finally found what we think would be a good candidate for high voltage generator. It is MC34063, buck/boost/inverting regulator which comes at a price of 56 cents from Digikey! However, it also has disadvantages, the biggest one is its maximum switching frequency which is just 100kHz. It automatically imposes much bigger inductance if compare with switching voltage regulators operating in 1-2Mhz. Values of 80…200uH are very typical for circuits with MC34063. In addition to that, due to low frequencies inductors must be capable of passing through currents 10 and even 15 times higher than the actual load requires. To some degree the price migrates from switching converter to passive components and it is important to be aware that in some circumstances it is just not worth using MC34063.
Another challenge is to calculator values of passive components, the quick approach would be to use already existing online calculators and there are few of them available, the problem is that they produce quite different results. We ended up using MC34063 Boost Converter Calculator as it looked more professional due to a mere fact that is distinguishes numerous flavors of MC34063 from different manufacturers. Filling in required input parameters we got the following results below.
There are few things worth mentioning though. First of all, the calculator does not give anything if negative Vout is specified. Looks like it is unable to calculate for inverting mode (well, not a big deal, it should not fundamentally change anything if we provide positive value for Vout). Secondly, the calculator doesn’t give any result if we specify Vout = 24V. Well, we specified 23V and going to adjust value either of R1 or R2 to get 24V. If the prototype works then we keep 24V otherwise will stick to 23V as it is still within the optimum range of VFD. And finally, the calculated inductance is so high that it becomes unpractical, it also seems too high when looking at the application examples in the datasheet. There is a good article about a PSU based on MC34063, the author also got extremely high (389uH) inductance as a result of calculation and decided to use 100uH. We will also reduce calculated value down to 180uH and see what happens during our experiments. The first revision of our circuit is given on the picture below.
MC34063 Inverting -24V
After getting all the required components we finally were ready to begin experiments in real life. The first prototype didn’t give any magic smoke but even without load applied there was current consumption of 70mA @ 5VDC input voltage! MC34063 was unpleasantly warm. High current in idle mode must be caused by pulses going back and forth through big inductor and frequency of pulses is in essence switching frequency. Then by ramping up switching frequency pulses of current through inductor should be less and therefore loses should be less… To check our assumption we then measured power consumption when using 1200pF and 600pF timing capacitor. In first case current consumption was 70mA, the second experiment gave 60mA. So we managed to bring down consumption by 10mA – not ideal but we were definitely going in the right direction. Using oscilloscope we confirmed that switching frequency increased from 40kHz to about 73kHz as it is shown on the picture below. Potentially we still had some space for improvement as we could increase the frequency up to 100kHz.
MC34063 1200pF @ 40kHz
MC34063 600pF @ 73kHz
The picture below shows that the PSU indeed generates -24VDC out of +5VDC, however, it still consumes too much when idling.
MC34063 5V to -23V PSU Idling
We are going to continue our experiments with the prototype to make it more efficient. It would also be quite interesting to know how good it is when it works with real load – all this will be done soon, stay tuned.
Stylish and professionally looking enclosures for DIY electronics is a known challenge for both beginners and advanced hobbysts. Custom made cases are either too expensive, too difficult/time consuming to build or the resulted forms are too primitive/ugly. Besides, electronics engineers usually are not exceptionally good at 3D designing and they tend to consider assembled and tested PCBAs as virtually finished products. As a result, the importance of putting everything in a box is often underestimated and even neglected. After all, who cares if the project ‘is working fine’? However, unappealing enclosure design may easily ruin the whole project even though its electronic part works like charm. That is why we decided to build something unusual as a case for our Luminardo board and today our goal would be to make a VFD filter. The problem with filter is that it has to be transparent which is almost impossible to achieve when using 3D printing. On the other hand, laser cutting on acrylic blanks could give us transparent part of virtually any shape but it would be flat. An alternative approach would be to find something transparent of a peculiar shape and use it as a blank for our filter. We looked around and found in one of Chinese shops a… plastic glass for just 3 Australian dollars. The glass is shown on the picture below.
Plastic Glass To Be As Filter Blank
The next step would be to cut a few elements off the plastic glass in the shape of visor. This was done by means of a rotary tool (Dremel) and finished with a double-cut flat file. The result is shown on the picture below, as an experiment we cut out three elements with variations in shape in size.
VFD Color Filters
To make sure that the filter fits the remaining parts of our enclosure (which we are going to design in Sketchup later) we need to create its 3D model. At a first glance it looks like a difficult job because of surface’s complexity but in reality it is fairly simple. The key is to start over with modelling of glass surface created by lofting technique (glass’ section and ‘follow me’ tool). Then cut off the excess of material just like it has been already done in the physical world by means of dremel and files. As a final touch apply material to adjust color and transparency accordingly to make it look like real. Here is what we got as a result of our effort:
1. VFD Filter 3D Model in Sketchup;
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
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
Of course, as any product is has its own pros and cons and here is the list below that we came up with:
- 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 );
- 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;
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.
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.
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 Bottom View
Luminardo Case Experiment Rear ISO View
Luminardo Case Experiment Bottom ISO View
Luminardo Case Experiment Front ISO 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 Bottom View
Luminardo Case Experiment Rear ISO View
Luminardo Case Experiment Bottomt 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!
1. Case for Luminardo in SketchUp, experiment “1″
2. Case for Luminardo in SketchUp, experiment “2″
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 Board Fitted In Case
Pilot Display Fully Assembled Back Lid Off
Pilot Display Fully Assembled
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:
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 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 Top