Let’s test out the capabilities of the DFR0299 audio player module, an ideal choice for Arduino but also for many stand-alone applications.

In this article, we decided to design and propose a demoboard for the DFR0299 module we already used in the ‘Presepino’ project; this module will function as a development platform for various application or just to program multiple circuits in the event of small productions.

The circuit

The module is able to directly play MP3 and WAV files saved on a FAT16 or FAT32-formatted SD-Card up to 32 GB; the card is to be inserted at the top of the PCB; however, the module also has an additional Device-type USB that we have brought on a USB A connector and that allows it to read data from a Pen Drive, again with a maximum capacity of 32 GB and with t same formatting of the SD-Card.

The peculiarity of this module is that it’s been developed and made for the Arduino environment and we have developed a dedicated library for its management which allows deciding which file to play, volume control etc. On the other hand, the device can also work autonomously and that is how we are going to use it, controlling via keys that allow us to manage very function. Since the module can be controlled through the serial interface at TTL-level, we are going to use a Serial/SB converter for our circuit in order to interface it with a Personal Computer. A serial port is still available and accessible in the diagram.

The module contains a decoder to decompress MP3 audio and a microcontroller capable of accessing, via SPI, to data contained on the SD-Card: the decoder transforms data stream in uncompressed audio as it reads it; the uncompressed audio is then amplified by a small integrated 3-watt bridged-output amp, which can easily be “heard” in the environment. If you need more power, you can still use audio output (SPK1, SPK2) in order to drive a proper BF amplifier to connect to a loudspeaker; alternatively, you can pick the audio from 4-pin and 5-pin, which are the channels low-level audio outputs, LEFT and RIGHT respectively. In this case you can have stereo audio.

Each of the module’s functions is controlled by keys placed on the printed circuit, as shown in the diagram, that we can now analyze after this introduction. As you can see, since this is a demoboard, all pins have been extended out, including TX and RX of the UART inside the module, working at 9.600 bps by default (we remind you that this module is aimed for Arduino, so a higher serial speed is not needed). In order to allow multiple-keys reading, we took advantage of a trick using the A/D converter inside the microcontroller assigned to ADKEY1 and ADKEY2 lines. We have employed such solution since reading the 20 keys would otherwise require just as many pins, which are not available in the module, since it is mounted on a PCB lined with 8+8 pins with 2.54 mm distance from one another, made of two strips with 8 pins each that are to be used for power, audio output, USB connection and serial port, besides stereo audio and loudspeaker output.

Key reading takes place by detecting voltage determined by pressure and subsequent closure of each one of them at the related connected input; said tension is dependent on resistance in series with the key. Precisely, both ADKEY1 and ADKEY2 are complete with a pull-up resistor inside the module functioning as a partition with the resistor in series with each key, determining a certain pressure every time the key is pressed; the firmware contains a value table, each value corresponds to ADC -reading  of corresponding values between ADC-reading for each pressed key, therefore, since the resistors for the 10 keys are all different, by closing Play Mode  a different voltage on ADKEY1 will be determined than the voltage occurring by acting on 01, 02, Loop and so on. Same goes for ASKEY2.

Of course, keys on either side must be pressed only once, otherwise two resistors would be in parallel and the A/D converter would read an anomalous value, thus determining activation of an unrelated function.

Keys are divided into functional groups: those activating direct track playback (in this case, for the key-based control, we are considering playback of 14 audio files), and those controlling working mode; the first group includes keys 01 to 14 and by pressing one of them, tracks contained in used or predefined mass storage device in corresponding positions are played back automatically. Hence, first track will be directly reproduced by pressing key 01, while pressing key 02 will play back track n°2 and so on up to track 14.

It is worth noting that the fourteen keys related to the memory segments in which just as many tracks are saved have two activation modes: short press starts playback while long press determines the track looping from the beginning.

Play Mode determines playback mode, namely choosing whether to play current track till the end or skip immediately to selected track (interrupted/non interrupted mode); each key press inverts mode. U/SD/SPI key manually sets source selection from which reading files that are going to be played back (U/TF/SPI/Sleep): each press switches from USB to SD-Card to SPI, in that order, while third press goes back into Sleep Mode and the cycle starts over. Third function key, Loop, allows to switch from single playback to loop playback mode: in the first case, track selected via buttons 01 to 14 is played back once for each press, while in the second case (loop) the track starts over and over again after each playback, until circuit is powered off or Loop key is pressed or Pause/Play button is pressed. The last key is indeed used to pause current playback, or to resume it if paused; this is true both in case of one-time playback and loop playback and does not affect settings edited with previous keys.

Next/Vol+ key also has a dual function: it allows you to skip from one track to the following once short-pressed. It effectively works as a skip button.

When long-pressed, it constantly increases volume (that is the level of audio signal provided to the outputs and to the integrated amplifier of the module) until released.

Similarly, Prev/Vol- key, (fifth function key), skips to previous track from currently selected track (track selected with 01/14 keys) if short pressed (e.g. the player starts reproducing track 4 if it is reproducing track 5), while it progressively decreases volume when long-pressed until release.

Regarding playback volume, note that volume starts from highest possible volume, so it has to be controlled with the keys (to be precise, you will have to act on Prev/Vol-) to suit your needs.

Alright, now that we have analyzed keys, which constitute the board’s user interface, let’s talk about communication ports, which are basically serial port (TX, 3-pin, and RX, 2-pin) at 0 – 3 V range and USB, which refers to USB-A connector and, internally, to the Device type USB: note that we are effectively using a USB to interface with the Personal Computer, but not the module’s, since this is factory-configured to be used as an interface for the Pen Drive from which files to play back can be uploaded, but we are using the serial port connected to a USB/RS232 module, that is the Open electronic’s FT782M

Since this module, based on the popular FTDI’s FT232RL integrated circuit, works with the 5 V of the USB connection and therefore works with TTL levels on the serial side, according to the manufacturer’s instructions we have inserted some resistances in series with channels TC and RX of the MP3 module, which has been designed to work with 0- 3,3 V levels. The pins used to connect the loudspeaker (6 and 8) have been brought to a 3.5 mm jack with conjoined left and right channels, while the SD reader is embedded in the module’s PCB and therefore is not present on the demoboard’s diagram.

The whole circuit is powered by direct voltage ranging between 9 and 12 V and the U1 integrated regulator, preceded by the D1-diode for protection against polarity inversion (which voltage is negligible), is powered by the stabilized 5 V needed by the MP3 module. C5 and C6 capacitors filter input power (jack+ and – PWR) while the regulator-stabilized 5 V voltage is filtered by C1 and C3. Down the module’s power line we can find C2 and C4 capacitors locally filtering the 5 V and preventing interferences propagating along power line from affecting the microcontroller that controls the MP3 module.

Use

As we mentioned, the demoboard supports MP3 and WAV files and automatically reads from Pen Drive or microSD if either is inserted, while if both mass storage devices are inserted, you will have to press U/SD/SPI key I order to choose track source, otherwise the module won’t play anything back.

In order for the MP3 module to recognize and correctly playback audio files by correlating them with keys, you must save them on the chosen storage device according to this format “0001_TrackName.mp3” where the filename must begin with the numeric ID composed of 4 characters, that is the track number of 4 digits: 001, 002, 003 up to 0014. You can replace NameTrack with whatever you want, the only thing is that it must be preceded by the number you want to assign to it and the underscore.

This way you can, for instance, control the demoboard through the keys, by sort-circuiting them with CMOS switches or with the lines of a microcontroller initialized as open-drain output, establishing a correlation between reproduced track and line to be activated.

Remember that the USB/serial control interface allows to manage the demoboard (or better, the MP3 module it is based on) from PC, but no specific software is provided; in fact, you can manage it by a terminal emulator software (e.g. Hyperterminal for Windows, or Telnet etc.) by following syntax and commands specified by the module manufacturer (DFRobot) in the User Manual that can be downloaded at main site

Remember that audio file commands are searched for by the microcontroller regulating the MP3 module based on folders, starting from the root of the mass storage and continuing in alphabetic order; to this regard, we must mention that the module supports a maximum of 100 folders and each folder can contain a maximum of 1.000 tracks. It is understood that the first 14 can be reproduced through the keys, while playback of remaining files can be sorted only via the serial interface, using the proper commands.  Supported file formats are those already mentioned and, more precisely, those corresponding to standard ISO 11172-3 and ISO13813-3 layer3 audio decoding, supported sampling rates are 8/11,025/12/16/22,05/24/32/44,1/48 kHz.

Volume control is divided into 30 steps (min to max); this is true both for the manual control via keys and for the control via the serial port. From the serial port, you can also choose one of the 10 sound equalization levels provided (e.g. Jazz, Classic, Pop, Rock etc.).

Still on the subject of communication via serial port, the PC-protocol requires this configuration:

– Data bits: 1

– No Checksum

– No streaming control

The required formatting, that is the command syntax to send through the serial port is $S VER Len CMD Feedback para1 para2 checksum $O, according to Table 1. As you can see, $S is the start bit and each string ends with end bit $O.

Table1

On the other hand,  Table 2 shows main commands that can be given to the module, the working commands controlling track playback functionalities; note that parameters can be found only in commands that need them, such as those indicating the track to be reproduced, volume level to be set, etc.

Table2

From Openstore

DFPlayer – A Mini MP3 Player

Demoboard MP3 audio player DFR0299

USB to Serial converter

Switching power supply 12 V-1,2 A

Our prototyping board acquires a 32-bit processor and sets the bar high, towards demanding applications that may take full advantage of the WiFi support, of the RTC and of the SD-Card, that make Fishino stand out from the common Arduino UNO. Second installment.

In a previous post you met our new and powerful Arduino-like board, that shines for having WiFi and RTC transceivers available on board. Now it stands out even more from the Arduino boards, because of the processor it uses; in fact it has been provided with a 32-bit MCU by Microchip.

We described the circuit diagram, and pointed out the features and the advantages (with respect to our Fishino boards that are based on an ATmega microcontroller); it is now the time to move on, to its implementation and activation.

Activation

Once you get hold of your Fishino 32, you will proceed to its programming that – as we could see in the first installment – may be carried out by means of the Arduino IDE. You will have, however, to install the package we supplied on the website: it contains all the additional programs needed (third-party software).

The package installation, thanks to the Arduino team’s work, is certainly a simple one: it is enough to start the IDE, to select the Setting submenu from the File menu and, while in the row named Additional URLs for the Board Manager. As shown in figure, it is possible to insert more than one path, by clicking on the button: a window will open, and by means of it, it is possible to confirm or search for new paths.

Once the Fishino path has been typed, it is enough to enter the Tolls  menu and to give the Board>Board Manager…” command: you will access the management panel for the additional boards; you will find the fishino_pic32 by Fishino package towards the end.

On the right, you may notice the Install button, along with a box, which is used for the version number selection. In the moment we write this article, the version number is 1.0.1, but the package is being continuously updated.

Please click on the button and the packages will start downloading, the process may even last for quite some minutes; do not worry, as this is an operation to be executed only once, at the start (or when updating the board, but in that case only the modified elements will be downloaded).

Once the installation has been completed, the screen will appear as in figure. You will notice that the Install button has now been replaced by the Uninstall button and that the list of the available boards has appeared: do not worry if it’ll be different from the one in the pictures: we’ve been studying to add more boards!

Once this operation has been completed, in the board selection menu you will find our Fishino32.

Now your Fishino 32 is almost operational; only the USB drivers are missing, and for some operating systems they must be installed (that’s not the case of Linux, as they will be included, and the same goes for MacOS X).

With regards to Windows, the drivers will be automatically downloaded, along with the software package containing the description of the new boards that we just installed; unfortunately, they are not automatically installed in the operating system; for technical reasons that it would be too long to explain here.

As for the installation it is enough – once Fishino has been connected to the PC – to follow the on-screen instructions, by manually searching for the drivers in the following path:

C:\Users\username\AppData\Local\Arduino15\packages\fishino\tools\pic32-driver-windows\1.0.0\chipKIT Drivers, please take into account that the name of the user for which you are installing the drivers must be typed in the place of username.

Once the Stk500v2.inf file has been selected, the driver will be installed and the corresponding virtual COM port will appear in the IDE. Once the drivers are installed (if needed), the system is ready for use.

You will now need to select the correct port in the IDE, it will be a COMxx on Windows or a TTYACMxx you are working on a Linux operating system.

Executing the first Sketch

And here we are, ready to test our board! You will immediately find out a small difference, with respect to Arduino and the 8-bit Fishino boards. At first, it may look as inconvenient, but actually it often turns out to be an advantage: the board does not have an autoreset, that automatically sets it to the sketch loading mode. Therefore, you will need to press the reset button, and to keep it pressed for about 2 seconds, until the programming orange LED flashes (but not for more than 4 seconds, or the update mode for the WiFi module firmware will be set: a condition that will be highlighted by the blue LED flashing).

If we missed the timing, that’s no big deal: let’s release the reset button and restart.

You might be wondering about the reason behind this functioning mode; well, it is because the board has a native USB, which is connected to the functioning of the controller itself, as in the case of the Arduino Leonardo boards. If the controller is halted(as in the case of a broken sketch) the USB port won’t respond to the commands, and not even to the reset ones. We, therefore, preferred a manual system that would prevent, as an example, the notorious ‘emergency maneuver’ that is sometimes needed on the Arduino boards (that consists of pressing the reset button “a moment” after having launched the programming from the IDE).

However, we do not rule out the possibility – in one of the next versions of the bootloader – of an automatic reset system, even though the abovementioned limits still remain.

Let’s return to our sketch; we will load the BLINK sample from the IDE: that’s the sample that makes the led13 (the one corresponding to the white LED on the board) flash. Let’s keep the reset button pressed for about 2 seconds and, when the orange LED starts to flash, we will press the IDE sketch loading button.

After a few seconds (it depends on the PC speed, on the sketch complexity, on the number of libraries we used, etc.) the loading will be complete: the fact will be highlighted by the orange LED switching off and by the white LED flashing at the same time.

That’s it: the board has been tested and is operational! And now?

Updating the WiFi module

If you read the articles concerning the 8-bit Fishino boards, you will surely remember that the firmware update procedure required some loose connections between the boards’ I/Os and the ESPCONN port, the preloading of a “neuter” sketch, such as for example the blink one, etc.

None of this is needed on Fishino32: the board is set to the firmware update mode, simply by using the reset button!

The procedure is as follows:

• please press and keep the reset button pressed, until the blue LED starts to flash; you will notice that 4 seconds are needed: after the first 2 seconds the orange LED will start to flash, so to indicate the sketch loading mode, and after 2 more seconds the blue LED will start to flash;
• please launch the FishinoFlasher program (downloadable from http://fishino.com), after having verified that your computer has a working Internet connection, given that the firmware will be downloaded from the wireless network, and thus from the Web.

Once started, the FishinoFlasher program will show a screen as the one in the figure; it is possible to notice some elements there, such as the type of the detected board (Fishino32), the WiFi module’s series number, and the currently installed firmware version (in this case, that’s 2.1.3).

It is possible to choose a new version to be installed, in the box below; the last available version is proposed (3.0.0, in this case), but nothing prevents the installation of a previous version, even though it is not normally advised.

Please pay attention to the fact that when changing to a “major” version number (that regards the first number on the left, that’s 3 in this case), a backward compatibility with the previous libraries will not occur. In practice, a library that has been installed and that works with the 2.5.5 version will work – as an example – with a firmware of the versions 2.5.7 and 2.9.9, even though it will not take advantage of the improvements, but the contrary is not true, that is to say that a library made for the 2.5.7 version will require a firmware having a version at least equal to 2.5.7.

On the other hand, that library will not work with a 3.0.0 firmware.

In brief, a library that was created for a firmware having a certain version number will work with all following firmware, having the same major version number, but not with the previous or following releases that have a different major version number.

This being said, let’s choose our version and click on the Flash button; after a few moments the actual update will start figure. At the end of the procedure, a notification window will appear, so to inform us about the fact that the update took place.

At this stage, it is enough to click on Ok, to close the FishinoFlasher program and to press the reset button on the board, in order to exit the update mode.

Available software-Libraries

We may subdivide the libraries into two logical categories:

• system libraries;
• user libraries.

That’s quite an artificial subdivision, given that – more or less – all the libraries could be considered as partially pertaining to both sectors; the true difference lies in their placement in the hard disk, and in the update modes.

The system libraries are placed in the arduino15 folder (depending on the operating system, it may be found under different paths) and they are managed and updated by the integrated board manager, while in the IDE. For example, the SD, the AudioCodec, the I²S libraries, etc. belong to this category. The IDE will notify about each available update and will give the chance to automatically download the updates.

On the other hand, the Fishino library – along with the FishinoWebServer one and other possible ones, belongs to the second category – but that’s a particular choice we made; in fact, this library depends on the WiFi module’s firmware version (and not on the board itself), therefore it must be updated according to it. Placing it in the system libraries would have compelled the user to update it – and therefore to update the firmware – for each update of the system libraries, which is not strictly needed. This library must be directly downloaded from fishino website (under the download section), as with all the previous boards; under that section you will also find some sample programs, such as FishinoHomeAuto.

The libraries under the download section are provided as .zip files, to be unpacked in the “libraries” folder, that is found inside the folder that contains all the sketches.

Once this procedure has been carried out, it is possible to try all the samples related to the WiFi module, as with the previous boards.

As for them, their functioning is the same as in the previous boards; you will just notice that the performances are remarkably better ones and, obviously, that the space occupied in the memory is certainly far from the board’s limits!

Now that you have all the power of Fishino 32 in your hands, you are ready to develop!

From openstore

Fishino 32

You already had the chance to see – and we hope, to try – our modular system for RGB LED matrix displays: LED Matrix (that’s the name) is a solution based on RGB LED matrices, that may be easily acquired (and at an affordable price) since they were born in the Maker world. We manage it by means of a controller board of the same name, that is an extremely powerful one since it’s the FPGA Spartan 6 by Xilinx, and it does not limit itself to the matrix management (that you could see in the previous installments) but – thanks to a specific firmware (bitstream ones, given that we are talking about FPGA…) – it may drive displays having a greater size, or that may carry out other tasks (that we will describe later).

The applications we proposed in the past  concern 32×32, 64×32 or 128×32 pixel (LED) matrices: and they are based on a free firmware, supplied with the board. There are also  paid extensions of the LED Matrix board, based on a paid firmware and they enable, as an example, to manage matrices having a bigger size, and to do that autonomously from PC, in the stand-alone mode. The latter is particularly valuable when you have to install a display in a place that is not easily accessible, or where you have to operate by continuously reproducing the same animation.

In these pages, we will describe the SD-Card section (that we omitted until now from the circuit diagram analysis) and the one that enables the “cascading”, needed in order to drive large matrices.

But let’s proceed step by step and first deal with the variations needed for controlling a display having a size that is greater than the one allowed by the board’s free version.

Extended Matrices

A single LED Matrix controller board may drive RGB LED matrix displays up to a maximum of 64×64 LEDs, and that are therefore composed of four 32×32 modules, arranged so to form a quadrilateral, and connected in cascade among them and to the board’s outputs. But the system enables the management of panels that are extended up to Jinx’s limit (that’s the viewing software for Windows,) which is 48,000 pixels, a limit that goes well beyond 64×64. However, because of the limits of the Spartan 6 capabilities, it is not possible to control of all of them with a single unit, otherwise the refresh will be slowed down, to the detriment of the video playback quality.

In this case, one would resort to the cascading, that is to say, to a particular configuration that enables the connection in cascade of more units, so to entrust the control of a pixel block to each one of them.

In the said mode, the board is connected to the computer and repeats the whole data stream towards the following one, by means of the BNC connection (that we omitted during the analysis of the circuit diagram, but we will soon deal with it); the board receiving the stream through the input BNC will repeat it on the output one. The following one will do the same to the following.

In the said mode, the FPGA firmware decides how to subdivide the stream’s pieces of data, on the basis of the configuration that is loaded by means of the terminal program; in other words, it is by means of the terminal that we decide and tell how the display is formed (we will later see the commands to give) to the board that is connected via USB; and at this stage each one displays only its part of data and repeats the whole stream on BNC. The BNC connectors are signed CN7 and CN8; they are respectively input and output. The board that comes soon after that one is connected in cascade via the other BNC and uses only the pieces of data that concern it, while it repeats the stream on BNC; it goes on like this till the last board.

A peculiarity of the FPGA lines that are repeated on the BNCs is that they are set so to operate in differential mode and are uncoupled on the demoboard by means of signal transformers (TR1 and TR2) with centre tapped secondary winding, that enable the galvanic isolation, thus ensuring a greater immunity to electrical noises.

Their processing will then be carried out by the FPGA blocks, that will be selected from time to time by the application’s firmware. Please notice that the term “differential” concerns the internal side of the board and not the BNC: in fact, the inputs are unbalanced at the BNC (that is to say, they are connected to a contact with respect to ground), while from the side of the FPGA they are balanced, that is to say, they refer to two I/Os. Each BNC is uncoupled by means of a capacitor in series to the signal wire, so that if some devices that have a DC polarisation are connected to the demoboard, the transformer does not act as load; moreover there is a 75 ohm resistor in series to each BNC, and it adjusts the input impedance to such a value. From the internal side, the transformer with centre tapped secondary winding (connected to ground) supplies two signals in phase opposition, each one of them – by means of R/C dipoles series (so to uncouple and stabilise the impedance) – is connected to a pair of FPGA’s I/Os.

A peculiarity of the cascading mode is that it enables the extension of the PC-Matrix connection beyond the maximum of 5 metres of the USB standard connection. Typically, the common USB 2.0 cables are capable of ensuring a maximum speed of 480 Mbit/s (USB 2.0 Full Speed) only with lengths of about two metres, even though the maximum distance supported is, in theory, 5 metres. This is due to the crosstalk and to the low or missing shielding of the cheap “consumer” cables, that moreover weaken and distort the signal, beyond a certain distance, thus forcing the USB controllers to decrease the speed.

Beyond this distance it would not be possible, therefore, to command the RGB matrix from the PC, but our LED Matrix has an ace up the sleeve, that consists in using the BNC connection that – since it is based on differential lines – ensures a very high immunity to noises, also by virtue of the low impedance of the connection, that has a typical value of 75 ohm (that’s not a case it requires a RG59 75 ohm cable). Therefore, if the PC is farther than the 5 metres allowed by the USB, we just need to connect it to a first LED Matrix controller board that in this case would act as a repeater, and then get the right BNC signal (CN8) and send it to the display block, at the BNC input (CN7) of the first controller board (that is to say, the one that drives the matrix that has been chosen first in the order). The firmware fully supports such a mode, meaning that it repeats everything arriving on USB, regardless of the fact that the board connected to the PC drives a part of the display or not. After that, the first board of the visualizer will analyse the stream incoming on its CN7 and will process the part falling within its competence, and repeat the stream on its CN8 (as we already explained).

In the said mode it is possible to connect the panel and therefore the first board in the chain, even at a distance beyond 50 metres, provided that the coaxial cable is a good quality one.

SD-Card Section

Let’s move on now to the playback mode from SD-Card, that is the stand-alone one, since you do not need to connect any PC. As for it, everything we said until now – with regard to the array modularity and the display support – is still valid; the only difference is that the cascading is not supported. In the said operating mode, the firmware searches in the SD-Card inserted in the controller board for the file to be played; the controller board has been opportunely instructed by the specific commands given from terminal, so to activate the said functioning mode. The file has to be the one generated by Jinx, by means of the dedicated function and the corresponding menu commands (that we will later describe).

As regards the concerned hardware, it’s time for a digression: in order to speed up the access to the Card, from which the FPGA firmware enables to execute the file containing the data needed in order to build the pictures in real time, we used faster mode, that is not the classic SPI (the one we were used to, thanks to Arduino and derivative boards, and that is used by the consumer microcontrollers); here we use the full-speed mode, and separate the pieces of data from the commands (that in the SPI-type buses travel on a single wire, on the other hand) and use as much as four bidirectional lines for reading and writing (they are DAT0, DAT1, DAT2, DAT3, and along them the pieces of data travel in packets that are then put back together at the right moment).

As regards the commands, we use the CMD channel and all the communications on DAT0÷DAT3 and CMD are seton the clock that the FPGA sends to the line of the same name. In the board, the SD-Card reader’s data channels (respectively DAT0, DAT1, DAT2, CD/DAT3) are connected to the FPGA’s lines, IO_L52P_3 (6), IO_LIP_HSWAPEN_0 (144), IO_L36N_3 (29), IO_L37P_3 (27); the SD-Card’s clock connects to IO_L50P_3 (pin 10) while the CMD channel goes to pin 11 (IO_L49N-3).  

With such a configuration, we manage to transfer data (if the Card we are using supports it) at a speed that may even reach 70 MB/s, and therefore 560 Mbps! That’s more than enough for the playback of files with animations, at the resolution that is envisaged by the biggest display supported by a board.

Unit configuration

Let’s move on now to the part you will probably be most interested into, that is to say, how to make up the modular panel; as hinted before, each board must be configured on the basis of the display it has to drive.

Therefore, the first thing to do is to decide and define the display architecture, and to remember that each LED Matrix controller drives two basic matrices that are connected in cascade by means of a flat-cable, and to use each one of the connectors it has, for the purpose (CN6 does the first part and CN5 the possible second one).

Therefore, if you have to drive a single block (16×32, 32×32, up to 16×64) you just need to connect it via CN4, while if you have to drive two, or anyway if you have to manage blocks that are composed of more than 32×64 pixels, you will also have to use CN5, with which to connect the second block.

This being said, it is the case to point out that we conventionally name a display block entrusted to a single LED Matrix controller as Tile (we will see how to carry out the configuration), the set of Tiles composing the whole display to be created is defined as an Array.

Please remember that when the Array counts more than one Tile, you will have to individually configure the controller boards, and to define for each of them their position inside the Array itself. Once it has been established how big is the Array, you will have to set the size of the single Tile, also on the basis of what you have available.

In order to configure the visualizer, as a first thing we have to launch the LED Matrix terminal, and after having chosen the virtual COM to which the board to be configured has been assigned, when at the command prompt (>) please type preset and press Tab: the screen will show the available options, having the Tile resolution (0=16×32, 1=16×64 ecc.) next to each numeric value of the parameter.

We now have to type preset, followed by the value identifying the Tile composition, that must be decided at the beginning, on the basis of the visualizers composition. As an example, if we want to create a 128×128 pixel panel – knowing that each board reaches a maximum of 128×32 LEDs – we will need four 128×32 Tiles, and therefore as many controller boards. Please remember that the 16×32 matrices may be connected only in a row, the 32×32 may be connected in a row or on a square, and the same goes for the 64×32 ones.

Let’s verify, for now, the current settings, by typing preset and Return; the screen will return the settings; while in there, at X-Resol. the Tile’s horizontal resolution is indicated. If different, let’s set the value we’re interested in – that is to say, 32×32 – and then give the preset 2 command: the screen will show the new situation, and will update the X-Resol. field.

By giving the Tileres command, followed by Return, you will be able to verify the Tile’s settings or to change them, if need be. It is needed, when writing the command, to leave a space between the comma and the y value, otherwise the command will not be executed and nothing is communicated from the terminal.

Once this has been done, the array size must be defined, therefore – and still from the terminal window – we will give the ArrayRes command, followed by Return. The screen will show the current resolution. By typing ArrayRes, followed by the x and y resolutions (that is to say, the number of horizontal and vertical pixels), you will set the array size. For example, as for our 128×128 pixel panel, we will type ArrayRes 128, 128 and press Return.

The last setting to be given is the one of the starting pixel (the one in the upper corner and on the left), that falls within the competence of the tile associated with the controller, in the full matrix (array): by giving the Tilepos x, y command, we define the first pixel, that in our case is 0, 0 for the first board (the one connected to the PC), 32, 0 for the second one, 0, 32 for the third one and 32, 32 for the fourth one shows the Tilepos setting.

Once this has been done, in order for the configuration to be permanent, we will have to type Save and to press the Return button.

At this stage, it is possible to assemble the system, but please keep in mind that the right BNC of the board that will be connected to the Personal Computer has be connected to the left one of the other board, by means of a RG59 coaxial cable (75 ohm) that has BNC connectors at the ends. After that, please power the LED matrix modules in parallel among them, by means of an adequate power supply, and cables having a section of 2.5 sq mm.

Figure shows our sample 128×128 pixel panel, that we created for our tests, and that is composed by four 128×32 Tiles, by two 5V switching power supplies (one for each half of the panel) and by four controller boards; you will see that each board drives the first 32×32 matrices via CN4, and the last two via CN5. Please refer to it, when taking the cue for your creations.

Setting Jinx

While in Jinx, you may manually configure the display structure or load a configuration file that was previously saved. As explained in the past installment, please proceed to the configuration of jinx, by means of the “setup->matrix options” menu, and configure the total panel size, then enter the “Setup->Output patch” menu and configure the whole panel by means of the “Fast patch” button. Finally, please enter the “Setup->Output devices” menu and configure the USB streaming interface you wish, by using the glediator protocol.

Once the whole has been configured, it will be possible to activate the streaming from the “Setup-Start output” menu.

Once the system has been configured, we strongly advise to save the jinx configuration from the “File-Save as” menu entry, so to easily recall it, when needed. Also, we would like to remind you that at the start, Jinx will automatically load the last configuration that was saved and used.

SD Configuration

Let’s move on now to the configuration of the SD mode: this is actually the same, but when opening the terminal and selecting the command COM, the C:\> prompt will appear, so to indicate that in the board a mass memory unit was found. We would like to remind you that the stand-alone mode requires that in the LED Matrix controller board the SD-Card option has been purchased and enabled, otherwise the Card will be ignored. In order to create a file for the SD-Card in Jinx, it will be enough to press the F4 button (at any time), and a window will appear: it will ask for the file in which to save the animation. The recording starts by clicking on Record and by specifying the path and filename you wish to create; once the file has been defined and you have clicked on OK, the computer will start recording everything happening. Whenever you want to end the recording, please click on OK. The corresponding file will be saved in the .jnr format.

At this stage, please get your SD-Card, that must be FAT32 formatted, then insert it in the reader that is integrated to the computer (or connected via USB to the PC) and copy the file there, after that – with the controller turned off – please put it in the specific socket. Please turn on the controller and launch the terminal on PC: you will notice that the C:\> command prompt will appear.

 As soon as the prompt appears, please type dir, so to see the files found  and then Play, followed by the name of the file you’re interested.

Please save the configuration by means of Save command; thus you will have created the file that, from now on, when turning on the controller board will be automatically executed, by visualizing the animation loaded in the SD-Card on the display (even with the PC being disconnected, and independently). The Play command, followed by the filename, and given from the terminal, is needed in order to carry out manual tests along with the unit connected to the computer. Please remember that in order to obtain the best performances as for the viewing speed (fluid animations), we advise you to use class 6 SD Cards, or even better, class 10 ones, given the high reproduction speed required.

VIDEO

From openstore

LED Matrix controller RGB

16×32 RGB LED panel

32×32 RGB LED panel

64×32 RGB LED panel

Cascading module enabling

Enable SD Card Module

A control unit for the garden sprinkler that can be controlled via web and smartphone thanks to Arduino Yún.

With summer approaching, our plants and our gardens need some regular watering in order to stay lush and green as we like them. It’s not easy to always remember to water plants and gardens and try to always be at home at the same time every day, so we asked ourselves, instead of taking some time every day to water plants and flowers, wouldn’t it be better to take advantage of our passion for electronics and realize an automatic system to do this for us? This is the idea at the base of the project we are going to show you in this article, which consists of a control unit for a garden sprinkler based on Arduino Yùn and a relay board that can interconnect with it. Control unit can manage a configurable number of outputs, a rain sensor and it can be programmed through a web interface reachable from any PC or smartphone connected to your home network. By adequately configuring the router where the sprinkler will be installed, you will even be able to control the system from the Internet.

But why did we employ a Yùn, instead of a common Arduino? The answer is that this allows us, thanks to its hardware which natively support wireless connections and Internet protocols, to manage the sprinkler via web and smartphone, thanks to an interface that is also designed for mobile devices.

THE PROJECT

Arduino Yún is the soul of our control unit. The project takes full advantage of the main characteristics of this Arduino, that is the possibility to simultaneously run a Linux distribution (thanks to Atheros’ System on Chip) and sketches (on the ATMega32u4 microcontroller it features). Linux operating system is in charge of managing graphic interface, memorization of programming and activation of outputs at set times, while the sketch executing on the microcontroller will take care of the interface with the external hardware: rain sensor, command panel with deviators (optional) and relay which activates the electrovalves.

In picture 1 you can see the functioning logic diagram: the web interface developed using JavaScript libraries according to AJAX paradigm (see box), receives data and sends out comments towards some pages written in PHP language and executed by the uhttpd Web server.

The PHP pages, therefore, communicate with the sketch through the Bridge library (used for bridging the Atmega-based Arduino hardware and the Atheros SoC) while programming and events are saved in an SQLite database. Some PHP scripts are executed periodically by the crontab (the scheduler) of Linux OS and they take care of activating programming and to periodically cleanout events and log. The sketch manages the control panel, reads the status coming from the rain sensor and activates outputs (electrovalves, pumps…) through external relays.

Circuit diagram

In order for the sprinkler to be able to manage our irrigation system, we have to connect it to some external elements. To simplify these connections, we have prepared a shield that allows us to manage a system with a maximum of four electrovalves, one rain sensor and one external command panel with four switches and four status LEDs. The circuit for the shield is composed by a voltage regulator which is crucial in order to power Arduino (via Vin) and by a certain number of outputs for LEDs and outputs for managing the electrovalves, besides four inputs for the command panel’s deviators, which are optional.

PWR is the power jack connector, and it needs a continuous voltage ranging between 8 and 15 V, which is filtered by the C1 and C2 capacitors and stabilized at 5 V by the integrated regulator U1. The OUT-pin of U1 provides its 5 V in relation to GND to the left side of JP5V bridge, which is used in order to decide the power source for the system: if we want to power Arduino Yún through the shield we have to close the jumper between the central contact and the left contact (in this case 5 V come from the Schottky D1 diode), while if we want to power everything using the Yún, this has to be powered with a dedicated adapter and the jumper must be closed to the right. In this case we must not power the PWR Jack of the shield, because the shield itself is powered by the Arduino’s 5 V, also via D1. Power source notwithstanding, the 5 V’s line also powers the pull-up resistors R2, R4, R6, R8 on the outputs which are linked to deviators and R9, connected to the dedicated input for RAIN sensor. In the next pages, we are going to explain how to use the latter.

The outputs are on OUT1, OUT2, OUT3 and OUT4 (D2, 3, 4, 5 of Arduino respectively) and provide the high logic level when the electrovalves must be opened; they are designed to pilot the relay board’s accepting TTL signals and independently powering the relays’ coils.

Setting up Arduino

In order to use the sprinkler, we first have to install some software packages in Linux operating system.

Using an SSH client (you can use PuTTY on Windows, on Linux and the Mac OS you have the ssh command) we connect to the console of Arduino Yún and insert our login info (by default, root is the user and arduino is the password). We also make sure the Yún is connected to the Internet.

First, we execute the comments to refresh the list of packages available for installation, which is:

opkg update

opkg is the package manager of our Linux distribution; through this command, we can install or uninstall applications and programs. In order to install the PHP interpreter (version 5) we can then input the comment opkg install php5. The package manager will download the latest version available – along with possible prerequisites – and it will install it in the figure.

We use opkg once again to install all other necessary packages for the sprinkler:

opkg install php5-cgi php5-cli php5-mod-curl php5-mod-json php5-mod-pdo php5-mod-pdo-sqlite zoneinfo-core zoneinfo-europe

We now activate the PHP interpreter in the uhttpd Web server by editing its configuration file with the command:

nano /etc/config/uhttpd

We have to erase the hashtag (#) at the beginning of the line relative to the .php extension as illustrated in figure.

We then press CTRL and X at the same time, then we enter Y to confirm the change. Lastly, we reboot the web server with the command:

/etc/init.d/uhttpd restart

To check if our Yún is now able to execute php pages, we can create a sample one by typing the following comments:

cd /www/

echo “<?=phpinfo(); ?>” >phpinfo.php

Now, if we open a browser on our computer and we enter the IP address of Arduino Yùn in the URL bar followed by /phpinfo.php, we should be able to see the info page of the php interpreter as shown in the figure.

INSTALLATION

Now we are going to download the last version of the software from the Github repository. Let’s go on https://github.com/lucadentella/irrighino and click on the Download ZIP button: after a few moments we’ll have a compressed archive on our PC with all we need to install our sprinkler.

Let’s take a microSD card and insert it in our PC; we are going to create a folder called arduino on it and, inside the folder, we are going to create a folder called www. Now we copy the website folder which can be found inside the archive we have downloaded from Github, inside the www folder; finally, we rename the website folder to sprinkler. If we did everything correctly, the microSD card will have a content similar to what is shown in the figure and we’ll be able to insert the memory card into the dedicated slot of our Arduino.

While still connected to Arduino via SSH, we type the crontab command and, in order to edit the scheduler configuration, after pressing the “I” button we input three lines, as shown in figure. We press ESC to save the configuration, then we type :wq and press ENTER. The three lines activate, every minute (* * * * *), the script that controls if there is a scheduled event to activate and once a day (from 00:05 to 00:10) the script to cleanout events and logs.

We are left with just one more step: loading the sketch contained in the Sketch folder inside the Github archive. Then, using the Arduino’s IDE, we open the sprinkler.ino sketch and we upload it on our Yún.

CONNECTIONS

In order to pilot the electrovalves we have to use functioning external relays powered by 5 V and piloted by the output pins of the Arduino. To this purpose, the shield makes use of the OUT connector, with a +5 V power source, ground and four digital pins of Arduino to activate as many relays. The connector is designed to pilot the 4 relays 5vdc module. This board is equipped with 4 relays with 5 V-powered coils and exchange allowing to commute electric loads functioning with a maximum of around 240 V and absorbing up to 10 A (max); each relay is activated by bringing the command input to high logic level (from 1,6 to 5 Vcc), therefore this board is ideal in order to actuate logic signals provided by the shield, also because its power absorption, on each input, is just a few milliamps, which is compatible even with CMOS and CMOS HC logics. All the inputs on the 4-relay board are optoisolated, so that we can make a galvanic separation between the board and the command circuit, should such a need arise; in each optoisolator, the anode of the input emitter diode (1-pin) is connected to its respective input through a current limiting resistor and the cathode is common to all the LEDs’ cathodes and the other optocouplers’ and it is connected to the input COM. If you want to give up insulation, you have to make a bridge between GND and COM.

Each relay is also provided with a status LED placed on the board’s edge.

The electrovalves commonly used for garden watering systems are powered by 24 V; therefore we will need a power transformer with a “secondary” which will provide such voltage and current needed to power all the electrovalves. One of the secondary terminals will be connected to the electrovalves, and one to the relays’s common node, as shown by the diagram on this page (connections). If you have just one electrovalve, you can use the connection shown in the figure, where you can find an example of valid connection for an electrovalve piloted by a single relay board.

If electrovalves are buried in a sump, you will always have to use waterproof connectors or junction boxes (IP65).

The rain sensor is usually composed by inter-digitized contacts that are grounded and everytime it rains, water connects them thus determining a strong decrease in resistance; the sensor is connected to the RAIN input and then, when it’s dry, it lets the Arduino’s D10-pin go to logic 1, while in wet conditions, water resistance acts as a partition with R9 and D10 presents such a low voltage that it corresponds to logic zero.

Some sensors, on the other hand, work thanks to a porous material which expands when wet and pushes the lever of a microswitch, while it relieves the lever when it dries out; these sensors are very accurate and adjustable, because you can use a screw to increase or decrease the microswitch’s distance so that it could be pushed only with a certain expansion and therefore with a set water volume absorbed.

Anyway, the sensor can be directly connected to one of Arduino’s digital pins through a pull-up resistor; if you chose to use the shield we have proposed in this article, all you have to do is connect it to the terminal box labeled RAIN.

Finally, you can also equip your sprinkler with a physical control panel, in order to operate it manually without the need of a computer: the set panel is composed of a switch with three stable positions (ON, AUTO, OFF) and a status LED for each output. The switch’s position is read through an analog pin of Arduino Yún, as shown in the related box, thanks to the particular connection of two resistances allowing to obtain a voltage value for each position.

Each panel switch, therefore, is used to manually force a condition on the corresponding output and therefore in the corresponding electrovalves; this condition is signaled by the specific LED. SW1 refers to OUT1, which is status is signaled by LD1, SW2 to OUT and LD2 and so on.

If we turn the switch to ON position, the related output is activated, while if we turn it to OFF position, the output is disabled. If we leave it in an intermediate position (AUTO) the output will follow the programming set by us. The panel has higher priority than the graphic interface, therefore if we set an output OFF on the panel this will result as disabled on the graphic interface and we won’t be able to modify its state.

The shield is already equipped with the terminal boxes to which we can connect the four switches and the pins to which we can connect the LEDs: for the LEDs, you must pay attention and correctly connect anode and cathode to the pins as shown in the serigraphy (the anode normally corresponds to the longer end).

The shield is also equipped with a voltage regulator (5 V) that allows you to power every external component independently in respect to Arduino. Through the JP5V jumper, you can choose whether to use power coming from Arduino or from an external adapter (9-12 V DC) connected directly to the shield.

Using the sprinkler

Let’s see now how we can use our watering control unit in remote mode: from a PC, open your Internet browser and, in the URL bar, type in the web address http://<ip_arduino_yun>/sd/sprinkler; from that page will be able to access the control screen of our unit.

The interface is divided into three tabs: Runtime, where you have the ability to manually pilot the outputs, Setup, where you can program weekly activations, and Events, where you can view a list with the most recent events (activations, configuration edits…).

Every output can be configured in three states: ON – output is activated; OFF – output is disabled or AUTO – output follows the programming. If the output is configured using the external panel, the corresponding commands on the web interface will be disabled, the panel has, in fact, a higher priority.

Programming phase is very simple, events are gathered in a table where columns represent days of the week and the single outputs (V1…). Each row represents a 5-minute interval: by clicking on a cell you can define an activation event. You can resize and move events using your mouse (in order to modify its duration), you can also move it on another output. By clicking on an event, this is selected and you will see a darker edge around it to highlight your selection.

You can select or deselect multiple events by clicking again on them while pressing Shift.

Finally, you can delete all selected events by pressing DEL.

Customizing the sprinkler

Although the project you can download from Github is configured to work out of the box along with the shield we have realized, the sprinkler is designed to be easily customizable in order to suit any needs.

By opening the include.php file, which can be found inside the PHP folder, you can edit the number of outputs, their name and the respective color, as shown in the figure. You can also add the behavior in case of rain (immediate stop of scheduled actions and/or no new activation) or completely disable it in case your system does not include it.

Connections between Arduino and the external devices can also be customized using the sketch. All the mapping between devices and pins which devices are connected to has been defined in a specific file, called config.h, which we have reported in List 1. You can, therefore, edit the pins that are connected to relays, switches, LEDs and to the rain sensor simply by indicating within the config.h file the desired Arduino pins. Remember, in case you are going to apply other shields to Arduino besides the sprinkler’s, always check that they are not already used by the respective applications before assigning I/O’s in config.h.

Always make sure the number of configured outputs in the web interface corresponds to the number of outputs (OUT_x) defined in the sketch and also remember to update the main sketch.

Finally, if you are not going to install an external control panel you can also inhibit functions associated with manual control by putting the USE_SWITCHES constant to false.

Very well, with that said, we have finished, we really hope you enjoyed this project!

From openstore

Shield Irrighino

Arduino YUN

Module 4 relays (mounted)

Let’s call back an electronic version of one of the most famous casino games: no tricks and no cheats…

The “roulette” is without a doubt one of the most famous and practiced casino games in the word, and it is surely one of the most widely employed, along with poker, in famous movies from all genres: from Westerns to police movies, from spy stories to comedy. Among the various versions available in the world, known as French roulette, English roulette and American roulette, we took inspiration from the first one, which is definitely the most famous; the main difference amongst various versions mainly focuses on the presence of the double “0” or lack thereof and on the disposition of black and white numbers.

Obviously, we couldn’t but present an electronic interpretation of our roulette, therefore we thought about how to design a circuit capable of reproducing the rotating movement of the ball thanks to the sequential lightning of a set number of LEDs. In the solution we designed and that we are going to describe in the following paragraphs, the ball’s circular movement can be obtained by piloting 37 colored LEDs in an appropriate manner and the final number can be outputted through unilateral lighting of one of those LEDs.

CIRCUIT DIAGRAM

The electronic part of our roulette is divided in two boards: control unit and LED panel.

In order to simplify but also making the realization of this project much more interesting, we took advantage of our dear old digital logics TTL/CMOS, however, in order to keep up with the times, we will use their modern versions which are HCMOS (74HCxxx). For a more in-depth approach to digital logics it would be very useful to read the theoretical introductions to articles presented on issues 170/171 (digital capacitance meter) and 182 (oroLED project), where we analyzed in depth both logic families and individual components used in those two projects, some of which are also used here. For this reason, we can also include this new project in our “vintage” line, since the whole component range goes back to the 70s and 80s of last century.

We are going to start by describing the control unit, let’s begin by saying the most difficult part of this project was being able to generate, through hardware only, a piloting clock for the counters that would start from a set frequency and then progressively decrease until reaching 0; this was used to correctly emulate the real roulette wheel’s behavior which starts off quickly and then spins slower and slower until it comes to a halt. In order to solve this problem, we took advantage of a particular configurator and the always-reliable NE555 (U1) integrated circuit. An astable multivibrator used as a clock generator for logic ports has been used as a base setup, and the components R1-R2-C3 set the starting frequency; the formula used to calculate the generated frequency in our case is:

F = 1,443/[C3 (R1 + 2R2)] =

1,443/[100 * 10-9(220000+200000)] = 1,443/(0,0000001*420000) = 1,443/0,042 = 34,37 Hz

Unlike the classic astable configuration, R1 is not directly connected to the +5V, since we placed a button in-between which is normally open, and its purpose is to start or stop the counting.

If we press and hold P1-button (which is placed at the center of the LED panel and its contacts go on the logic circuit through CN1’s 5-pin and 6-pin, responding to CN4’s 5-pin and 6-pin) on the output of NE555 we are going to actually have a fixed frequency equal to around 34 Hz (real value depends of course on tolerances of the three composed used); at the same time, C1 capacitor is charged through R3 (which purpose is basically to prevent the shock following the short short-circuit created every time we press the button when the capacitor is empty). Once we release the button, C1 capacitor starts to discharge through R4, and this causes a gradual decrease of voltage on R1 and, as a consequence, a decrease of output frequency from NE555’s 3-pin, passing from initial 34 Hz to 0 Hz. It is therefore clear that if we want to increase or decrease starting frequency we have to modify the values of R1-R2-C3, while if we want to either increase or decrease the “ball’s spinning time” we’re going to have to increase or decrease the value of C1 capacitor or possibly even the value of the discharge resistor R4.

On NE555’s 3-pin we take this variable clock and we are going to directly apply it to 14-pin of U2 (74HC4017), which is a x10 counter/divider; in fact, with each clock cycle applied to 14-pin only one of the Q0-Q29 outputs, sequentially, goes to HIGH level. Lines from Q0 to Q6 provide positive power and as many –LED groups (1-pin to 7-pin of CN2 connector, which corresponds to CN3 connector of the LED panel), while lines from Q7 to Q9 are powering three groups of 3 LEDs each through 8-pin to 10-pin of CN2. This Integrated circuit, therefore, only plays the role of unit counter, once it activates Q9 it starts over from Q0 but at the same time it sends a clock impulse (through its 12-pin) to 14-pin of the second U3 counter (another 74HC4017), which activates a sequence (similarly to what we just saw for the unit counter) in its Q0÷Q3 outputs, in order to manage ten-counting. Each one of these outputs is buffered by one of the BC547 transistors labelled T1÷T4, in order not to overload the counter although, in actuality, the 20 mA current that the two outputs of the integrated circuits can provide should be enough to drive the high luminosity LEDs we have employed. Notice that, although we have used transistors in their typical common emitter configuration, we added just one common limiting resistance (R5), instead of using four individual ones for each collectors as one would normally expect. The reason why we have used this “trick” is that only one LED will be on each time, among the 37 that we have on the panel, this way we can save to some precious space on the logic board, without damaging the LED piloting. The four transistors’ collectors are therefore positively powering the four LED rows (three 10-LED rows and one 7-LED row).

In short, functioning is the following: let’s suppose, for instance, that at the beginning both Q0 outputs are active: first LED lighting up will be the green LED (number 0, green), because it’s the only one receiving a positive voltage on the anode and the negative voltage on the cathode; at the following clock impulse U1’s Q1 output will be activated, while U2 stays on Q0, lighting the red LED (number 32, red); the following clock cycle will activate U1’s Q2 output, while U2 stays on Q0, therefore now the blue LD10-LED will light up (number 6. Blue), and so on until activation of Q6 output of U1 and Q3 output of U2 that will turn on the blue LD36-LED (number 26, black). Since there is no following LED, the system will reset itself starting from the green LD0-LED, then the next clock cycle will activate outputs Q7 of U1 and Q3 of U2; in this singular situation, NAND port “D” of U4 (a 74HC00) will have both inputs and HIGH logic level, on its output we will find a LOW logic level that will be inverted and brought to HIGH by the NAND port “C” of U4, which is used in inverter configuration (that is with the two input pins connected together); in order to better understand this mechanisms, we once again invite you to read the articles we referenced at the beginning of this article. The HIGH signal simultaneously applied to RESET pins of U1 and U2 will instantaneously lead to activation of both Q0 outputs, and the cycle will start over when LD0 lights up. Basically, we realize a simple but effective matrix with 37 LEDs, by assigning each one of them a color corresponding to the original French roulette; we used a green LED for the zero, red LEDs for the same color and blue LEDs for black, but if you’re going to use a mask with the classic representation of striped-band colors, you can easily use the same color LEDs, we think the most appropriate would be white or blue, in order not to play tricks on the dealer’s eyes!

Randomness is absolutely guaranteed because, although frequency range is basically fixed, running time of the “ball” will change each time, that is the following lighting up of the 37 LEDs with highly depend on pressure time on P1 button but also owned existing operational conditions of C1 capacitor, and we know that temperature differential and functioning time will also influence its charge and discharge times.

Finally, as we can clearly see from the diagram, we decided to bring the clock outside, through the OUT BF output, and send it to a small audio amplifier; we used a small 2846-PAM8403POT module that you can purchase on www.futurashop.it and that was featured and issue 198 (2x3W amplifier), with stereo inputs and outputs, a power of 3+3 watts on 4 ohms, 5V supply and volume potentiometer with on-off switch; once connected to a small loudspeaker, the result is exceptional, because you can replicate the noise of the ball spinning inside the plate, the noise gets slower and slower, perfectly synchronized with the LEDs’ movement, because we actually used the same clock.

You can use any other audio amp system, provided it malfunctioning or even freezing the entire circuit.

The circuit absorbs around 70 – 80 mA so it can be powered either with a 5V wall adapter or a battery pack with compatible characteristics; in this case you will of course have to rethink the packaging solution we proposed.

PRACTICAL REALIZATION

The electronic part for the roulette is placed on two printed circuits, one containing power supply logics and input (logic board), while the other one is the display panel, a round panel to honor tradition; this one contains the LEDs and the button to launch the “ball”.

In order to finish assembly, the two female header connectors must be welded together, perfectly perpendicular to the PCB.

Picture  shows the mounted logic board. Notice that, in our case, power connector is mounted on the welding side; the reason for this is that JST connectors often have an open female plug and their red and black wires do not have a standardized polarity; therefore the socket must be welded in such a way to match red wire with the positive +5 V input, indicated on the serigraphy with n°1, and the black one with ground. You can then go on and mount the LED panel, and you must pay close attention to colors here, and follow our instructions to the letter, otherwise you will have problems interpreting the outputted number for each corresponding LED lighting up; you also have to pay attention to LED polarity, and follow the indications on the serigraphy. The criterion to follow is very simple: the first LED (LD0) is the only green one, each odd-numbered LED on the serigraphy (LD1, 3, 5 etc.) are red, while each even-numbered LED on the serigraphy (LD2, 4, 6 etc.) are blue; moreover, red and blue LEDs are always alternating, there will never be two LEDs of the same color next to each other. In our prototype, LEDs are completely embedded in the PCB and directly in contact with its surface; if you prefer to mount them higher you of course have to create a space because the “ball” effect needs them to be on the same height.

The LED panel can be mounted with two male strip connectors, which must be of adequate length taking into account that P1 button will be placed on the central section; connectors used in the prototype in the picture are 3 cm long. P1 button will be inserted in a lower portion of the panel and is fixed with a nut on the bottom, therefore it has to be connected to the two specific emplacements with two wires that you are going to weld.

FUNCTIONING

Once the electronic and mechanical part is mounted we can finally move on to test phase. All you have to do is connect a 5Vcc power adapter (watch out for polarity!) And press and hold P1 button; if everything goes well, you will see LEDs lighting up sequentially and clockwise with a speed of around one full circle per second. Once the button is released, the LEDs will continue “rotating” for around eight or nine full circles with decreasing speed until they stop completely, on a randomly selected LED.

A good way to make sure the outcome is absolutely random is holding down the button for a number of seconds that varies every time: this way the cycle effect was start upon release and from a non-identifiable point due to maximum rotational speed.

If one or more LEDs do not light up during rotation you have to verify if both pins for each LEDs are welded or if they are inverted. If an entire 10-LED section or 7-Led section doesn’t light up (LD0 to LD29 or LD30 to LD36), or a group of four interspersed LEDs, you have to check the welding of strips and headers (CN1÷CN4) and the correct functioning of related transistor or the piloting integrated circuit (U2 or U3). Finally, it might happen that there is no rotational or the rotation behaves abnormally; in this case the problem with almost certainly be in the NE555; if you have connected in amplifier to related BF output you will have to disconnect it and verify that everything works. If this is the case it means that the amplifiers input has a low impedance and the oscillator becomes overloaded, or it has a malfunctioning which determines an excessive load and decreases the clock.

If rotational frequency is too high or too low you must verify the values of R1, R2 and C3, while if rotational time is too low or too high you have to act by respectively increasing or decreasing value of C1 capacitor or R4 resistance.

From openstore

Roulette electronic LED

Designed for small amplified audio speakers or as output stage for MP3 players, radio receivers or compact hi-fi systems; it is based on a class D integrated circuit which, thanks to the high efficiency, is ideal for battery-powered solutions.

Small power amplifiers for battery-powered audio devices must satisfy two requisites, which are essentially low consumption and reduced thermal dissipation; the two things are, in a sense, opposite faces of the same coin, because low heat dissipation means that output power being equal, the circuit loses small amount of power in its final stage. When power is taken from a battery it is crucial to save energy as possible, in order to obtain higher autonomy. The project we propose in these article was designed in order to offer a device requiring the lowest possible current, output power being equal; in fact, it is a class D amplifier, which is different from class AB (and even more different from class A) due to its really high efficiency, which can go up to 90% or higher (compared to 60% of class AB). This means that in order to provide the maximum 2.8 W to the speaker, this circuit needs a power of just 3.1 W. In order to obtain such characteristics we chose to take advantage of an integrated SSM2305 by Analog Devices, which is a complete filter-less SMD class D stereo amplifier, so it doesn’t require an L-C output filter; actually, as you will see in the circuit diagram that we are going to analyze shortly, there was a filter, but the term filter-less is generally used to indicate class D amplifiers that do not require tuned circuits and big-sized coils since they work at really high frequency.

Using an integrated SSM2305 allows us to omit a heat radiator therefore reducing the size (the printed circuit measures just 20 x 40 x 10 mm) and it also allows us to insert the circuit in containers without airflow, since we have very little heat to dissipate.

Class D

Before moving into analyzing the real circuit we would like to take some time to explain what class D is and how such an amplifier works: the amplifier’s hearth is the PWM modulator and it is necessary because class D is based on the modulation of impulses’ width, meaning that the audio signal is converted into impulses of equal amplitude, and their width is directly proportional to the amplitude of the input signal. Class D configuration is used in order to increase efficiency when it is necessary to keep dimensions, consume and dissipate heat on the low side. The PWM amplifier typically works like this: the audio signal is introduced on the non-inverting input of a voltage comparator, while on its inverting input a triangular shaped voltage of the same amplitude but with a frequency 10 times higher is applied (but it can also be much higher); on the comparator’s output there is high level voltage when the audio signal exceeds the triangular wave and a low level in the opposite case, therefore a series of impulses with constant amplitude and frequency, but with varying period duration which grows proportionally to the audio amplitude (with the same frequency of the triangular wave). By amplifying the impulses’ power through a transistor stage and by filtering them with an L/C low-pass filter, we rebuild the input audio signal. The class D amplifier is an example of how we can treat an analog signal by using impulses that can only assume two voltage levels and which allows us to obtain a really high efficiency because the transistors powering the load do not work in linear zone but on an impulse base, switching on and off (they behave as static switches); in fact, by using MOSFETs, which have an on-state resistance of a few milliohms, we can limit the power consumed in the final stage reducing it to negligible amounts. Despite powering the speaker by impulses and therefore with digital signals, the amplifier is still analogic because impulses’ width and therefore the mean value of the voltage applied to the speaker is linearly proportional to the amplitude of the input signal.

Circuit diagram

Let’s take a look now at the amplifier’s circuit, which is basically contained in the integrated SSM2305; this is a complete class D mono amplifier designed for mobile applications that contains a differential input buffer (which inputs refer to 3-pin and 4-pin, non-inverting and inverting inputs respectively) and a PWM modulator that receives a triangular reference signal for the comparator. A dedicated processor implements a distributed spectrum modulation to reduce output interferences. The rectangular signal obtained by the modulator drives a bridged MOSFET stage with complementary symmetry (which means it is composed by two transistors turning on alternatively), providing current to the speaker and without reference to ground, it has in fact to be connected to 5-pin and 8-pin.

The oscillator from which we take the triangular wave for the modulator works at fixed frequency that is set to 280 kHz by the internal components of the integrated circuit, more than enough to cover the audio frequency.

The IC requires very few external components, which are essentially a couple of capacitors for decoupling inputs, two resistors to limit amplification of the input stages and a couple of inductors and as many capacitors on the outputs. The resistors connected in series to the inputs are used to set the amplifier’s voltage gain and represent the inputs resistances of amplifier stages in inverting configuration, because retro-action of each channel of the IC1 follows; the internal retro-action resistance (Rf) is fixed and equal to 296 Khom, we can act on the gain (given by the Rf/Ri ratio, where Ri is the resistance connected in series to the considered input) and by choosing an adequate value for R1 and R2. Actually, the IC already has a connected network inside with values for Rf and Ri set respectively at 296 and 37 kohm, and this sets the voltage gain to 18 dB if there are no resistors connected in series to the inputs; 18 dB is a bit less than nine times, this means that in order to obtain maximum output power on 4 ohm each channel must receive a voltage input of 350 mVeff.

Preset gain can be reduced by inserting resistances, which are R1 and R2 in our diagram, both can be bypassed using bridges SJ2 and SJ2; by inserting the resistances (and therefore opening the pictures) the gain is reduced to:

G = 296k/(37k + R)

Where R is the value of R1 or R2.

We must remember that the output resistance of the source for the audio signal that we want to amplify affects the gain, because it is connected in series to the inputs, therefore the exact amplification also depends on that.

Now, let’s move on to the output; we can see that each one is filtered by a L/C cell composed of an inductor for EMI filtering (Electro Magnetic Interference) which is connected in series to it and a capacitor connected in parallel to the speaker, which purpose is to (almost) suppress impulses, by presenting a voltage which has the same waveform of the input but is of course amplified. Inductors are made by Murata following 0603 format per SMD and their impedance is 120 ohm at 100 MHz with a direct current resistance of just 50 milliohms.

Final elements for the circuit are the inversion-protection diode (D1) connected in series with the positive power terminal and the filter capacitors for power itself (C3 and C4), besides LD1 LED, which lights on to indicate power (R4 limits its absorption). Finally, note the P1 bridge that allows us to put the amplifier in standby; in fact, when /SD pin is left on logic zero (thanks to the pull-up resistor R3) the IC shuts down, therefore stopping the oscillator and the PWM modulator, besides turning off the power stage. This way the amplifier consumes just 30 milliamps. You can swap the jumper with a logic circuit to maintain the /SD line to zero when the amplifier must be turned off and to bring it to logic 1 when the amplifier must be turned on. This control is ideal for on/off switching with an integrated MP3 player or similar.

From openstore

Class D audio amplifer – mono 2.8 W

It measures solar radiation and visualizes the corresponding value on the integrated display of a miniaturized Arduino, in order to tell us when to expose ourselves to the sun…

Summer is just around the corner and whether you choose the seaside or the mountains for your holidays, there is no doubt that most of the people look for a sunny summer in order to come back with the most enviable suntan. Since sunlight contains ultraviolet rays, which are by the way responsible for our suntan, the first concern when it comes to sun rays is to protect ourselves, at least during the first days, with a sun lotion of adequate protection and by taking care to remain outside as little as possible, unless we have a sunshade or a sun umbrella. It is also useful to know the UV quantity contained in the sunlight, in fact, according to our geographic location and weather conditions, the atmosphere can retain UV rays more or less effectively. Getting to know the concentration (index) of UV rays is important because UV rays do not only cause sunburns but are also responsible for skin tumors, that is why we should try to get only the good part from the sun, which is composed of visible light or infrared light, and keep ultraviolet rays as far away as possible. This is the same reason why it is not recommended to sunbathe too long in certain geographical areas and on certain days. On an international level, UVI or UV index is the recognized parameter used to classify UV rays intensity, which is better described in the box you will find in these pages; that’s why in this article we are going to show you how to realize a device to measure and display the UV index, that you might use in order to verify the quantity of ultraviolet rays you are exposed to during your sunbathing session or, if you stay in the city, this will tell you when not to go out during the hottest afternoons in July and August and when you can go out with peace of mind, especially if you suffer from skin problems.

The circuit

Upon deciding to go on with this project we asked ourselves a few things, such as what hardware to use and especially how to detect the intensity of ultraviolet rays, how to elaborate it and what solution should we employ to visualize it. We had no doubts about the sensor since we decided from the start to take advantage of an easily available, conveniently priced product that can be connected to any hardware. Specifically, we are going to use the ML8511 sensor in this project, that is directly mounted on the 6168-UVSENSOR breakout board.

The sensor is sensible to UV-A and UV-B radiation and can provide a voltage output ranging from 0,9 V to 2,9 V (provided it is powered by a voltage not lower than maximum desired output voltage). The ML8511 sensor can detect UV light with a wavelength ranging from 218 nm to 390 nm. As for the output, the sensor provides an analog voltage which is linearly proportional to the UV intensity expressly measured in mW/cm².

In our case, we decided to display the corresponding value through a very particular displaying element that is integrated on the same board containing the microcontroller and manages both image processing and composition; it’s an Arduino-based hardware, but it’s not on one of those standard boards, because we opted for a peculiar version equipped with a matrix display, called KeyChainino, already published in this post and documented on the website. This board is a minimal version of Arduino based on an Atmel microcontroller from the ATTiny series and it’s equipped with 3 V power, more than enough for our purposes, moreover, it has a LED matrix that is used in order to display the UV index. The 3 V power allows us to connect the board to the same power line of the UV sensor.

KeyChainino is a “display” which is entirely realized with a LED matrix controlled by a small microcontroller integrated into a printed circuit as big as a keychain. KeyChainino is composed of a 6 x 5 LED matrix and two buttons, everything is controlled by tiny ATTiny84A, an 8-bit Atmel microcontroller in SMD execution, which has just 14 pins, therefore it is small enough to allow us to place the whole circuit in a small plastic container. Since the Atmel microcontroller has a few pins in order to pilot the matrix LEDs, it employs a particular piloting technique called Charlieplexing, which is a sort of multiplex characterized by the fact that each LED of the matrix works only whenever the voltage at its terminals is such to polarize it directly. Thanks to a suitable connection and by positioning the LEDs as you can see in the circuit diagram, and by taking advantage of the fact that the pins of our microcontroller can enter three logic levels (HIGH, /LOW, Three-state), we can pilot more than one LED with one I/O.

The three-state level is obtained by setting a pin to make it work as digital input, it then enters in high impedance therefore strongly limiting the current passage (it basically behaves as an open circuit).

KeyChainino employs a 3 V CR2032 cell battery as power source, which is mounted on the board; unfortunately, our tests showed that this battery cannot provide the system (including the sensor) with an adequate level of power for longer periods of time, therefore we opted for two AAA batteries connected in series, in order to obtain 3 V. To provide a longer autonomy, we have added a switch connected in series to the power source, allowing us to power the device only when needed; this lets us to sensibly reduce power consumption and therefore extend the autonomy; as a matter of fact the system, even in standby, absorbs around 450 µA (in standby conditions, that is with the electronics part powered up and the LED matrix off).

Everything is interconnected as shown in the diagram you can see in these pages, you will also notice that the sensor output is connected to one of the contacts reserved to the ICSP connector with which we initially load the firmware into the microcontroller; three lines available on that connector, once the sketch is loaded, are available as I/O: they are MISO (1-pin of connector and 8-pin of ATTyny), MOSI (4-pin of connector and 7-pin of microcontroller) and SCK (3-pin of connector and 9-pin of microcontroller).

On the KeyChainino’s board, we’re also going to install a dedicated sketch that allows us to read the voltage provided by the UV sensor coming on the PB4 line mentioned above, which is initialized as analog input and then assigned to the A/D converter of the ATTiny.

Functioning

After powering the system, the sketch initializes the I/O lines and then goes on standby, waiting for an event to occur, which corresponds to pushing one of the KeyChainino’s buttons; until then, voltage on PB4 is ignored.

In order to start the reading and visualization process of the UV index, we just have to push either button, then the microcontroller starts reading voltage on PB4, provided by the sensor, and since the sketch contains a conversion table from voltage to UV index, the dedicated visualization routine pilots the LED matrix in Charlieplexing in order to show the corresponding scrolling value (only the integer part, without any decimals).

Once the key is released, after UV index is fully visualized, the LEDs will turn off.

If you want, as long as you keep the key pressed down, you can continually visualize the UV index measure, which will be updated and displayed only after calculating a mean value from a series of acquired values.

The sketch

In order to simplify the firmware’s compiling we decided to start from the “KeyChainino_basic” provided along with KeyChainino, which is the project’s original one; it contains the reading of the keys and the LED matrix handling in Charlieplexing, so it makes our work much easier. The firmware has been modified by adding the part that allows us to read an analog signal through the I/O foot and the A/D converter. To this purpose, we have left some comments for the instructions for the activation of the ADC converter, in order to take advantage of it in our case. Instructions with comments can be found in the setup() function and you can find them below:

<em>ADCSRA &amp;= ~bit(ADEN); //disable ADC</em>
<em>power_adc_disable(); // disable ADC converter</em>

Moreover, the loop() function has been modified in order to allow sensor reading when either one of the buttons on the KeyChainino expressed. In List 1 you can see such modified loop() function.

Listing1

void loop() {
if ((digitalRead(BUTTON_B)==LOW) || (digitalRead(BUTTON_A)==LOW))
{
digitalWrite(UV_EN,HIGH);
showAnalog(LetturaSensore());
}
else
{
digitalWrite(UV_EN,LOW);
goSleep();
}
}

For what concerns, on the other hand, the reading of the sensor’s value, we have used three interconnected functions. The first one is LetturaSensore() and it allows reading from analog port A5 of Arduino (this corresponds to pin PB4, which is ADC5 input of A/D converter in the Arduino mapping) from which a mean value will be calculated starting from a set number of read values defined by the “num_letture” variable, then the UV index will be shown (List 2).

Listing2

// Reading the analog value of the sensor
int LetturaSensore()
{
int uvVal = mediaAnalogRead();
float uvVolt = 3.0 * uvVal/1024;
float uvGrado = mappaValori(uvVolt, 0.99, 2.9, 0.0, 15.0);
uvInt=uvGrado;
return uvInt;
}

The second function employed is called mediaAnalogRead() and it allows to cyclically read the voltage value on port A5 and to calculate the average of various readings, in order to have a stable reference value that will be then used as a term of comparison (List 3).

Listing3

// Average after a certain number of readings established
// from the variable "num_letture"
// The resulting value is sent out of the function
int mediaAnalogRead()
{
unsigned int Valori = 0;
for(int x = 0 ; x < num_letture ; x++) // The average is done
Among the values read to have a true value
{
Valori += analogRead(A5);
}
Valori /= num_letture;
return(Valori); // Calculated mean value
}

The last function we used is called mappaValori() and it allows us to obtain the UV index (sensor surface radiation) related to the value read; the function, which can be found in List 4, makes use of the conversion table pertaining to the output voltage of sensor for the UV index which is memorized in the microcontroller and it employs a floating variable.

Listing4

// Based on the average value and range of sensor values, it is calculated
The UV Index
// The UV index is returned as a FLOAT output function
float mappaValori(float val, float v_min, float v_max, float uv_min, float uv_max)
{
return (val - v_min) * (uv_max - uv_min) / (v_max - v_min) + uv_min;
}

From openstore

KeyChainino – programmable keychain

Module with UV sensor ML8511

It allows us to detect the presence and passage of an object thanks to the combination of a laser diode which emits a light ray and a phototransistor which detects reflected light.

Robotics applications and industrial control systems normally make use of optical systems in order to detect proximity and passing of objects, taking advantage of light interruption or light reflection on a surface of the object to be detected. In this article, we want to show you the project of a laser barrier: however this is not an interruption-type barrier, which needs the object to be detected to pass through a meter and a photodetector, in fact, this is a reflection barrier: in our circuit, a laser projects a ray of focused and infinitely-collimated light and any object passing in front of it will reflect a portion of it, which will be intercepted by a lens on its way back and focused on the sensible surface of a photo-sensible component. In this barrier, therefore, the object to be detected doesn’t have to interrupt a ray of light but direct it towards a photodetector. One advantage of this type of device is that it doesn’t require the placing of a sensor at a distance, with the inevitable wiring required, in fact, it concentrates all the electronics needed in just one place and therefore it is ideal for mobile systems like wheeled robots or robots on tracks. Typical detection distance is 80 cm but he can reach a maximum of 1.5 m; everything depends on how dark and absorbent the object is, in other words, how much light does its surface reflects. The circuit, thanks to its nature, can be used in order to detect obstacles, as a unit counter on a conveyor belt, counter for people passing through a gate etc.

Circuit diagram

So, let’s take a look at the circuit, where we can see that it employs a laser as the transmitter and a phototransistor-based module (labeled H2) as the receiver. The beam emitted by the transmitter is reflected on the surface in front of it and it hits the lens (its purpose is to focus the reflected light on the phototransistor) of the emitted by the LASER and avoids disturbances from other light sources.

Laser diode is a small pointer (which is a component integrating a laser diode which is cooled by the dedicated casing, a voltage regulator, and a collimator lens) and it is labeled LASER in the diagram and is powered through the Q1 transistor (a BC817 mounted in common emitter configuration) which base is piloted by the 180 kHz rectangular signal locally produced by an oscillator; this is labeled H1 on the circuit diagram. For every high logic level coming to the 1-pin of the oscillator (2-pin being the 5 V power source of the oscillator module), the transistor goes in saturation and powers the laser diode, which emits a light impulse; during the process, the transistor is in interdiction and the laser diode is turned off. When on, its current is limited by Q1’s collector resistance (R5).

The light impulses are sent out frontally and when they hit an object with a surface capable of reflecting at least part of them, they come back to the circuit, where part of them hit the phototransistor’s lens that conveys them on the exposed junction; if the portion of reflected laser light reaching the phototransistor is sufficiently intense, the junction shows free charges (we are talking about electrodes, because transistor is an NPN, although for every electron moving out you also get an electron hole…) forming the base current, which is then amplified by the collector’s electric field, thanks to the 5 V power reaching the phototransistor’s collector from the 3-pin (ground – 1-pin – relates to the emitter’s resistance). The phototransistor makes the signal of its emitter available on 2-pin and the signal is sensible to infrared and visible light; it is in common collector configuration, so its collector is powered through contact 1 and contact 2 provides around zero volts with no light and about 4 V on the base when receiving light.

Q2 transistor, which is a BC817 also mounted in common collector configuration, is in saturation when on standby due to the pull-up resistor R7, which polarizes its base through R9; the condition is highlighted by the lighting of LED labeled DAT, which current is limited by R6 resistance. When the phototransistor is hit by a light of sufficient intensity, its collector drops from 5 V to a little less than 0.7 V, such voltage is not enough to keep the polarization of Q2’s base, which goes now in interdiction and its collector switches to high logic level. This line can be read by a microcontroller in order to detect the presence of an object; high logic level is 5 V and the low logic level is around 0 V, so the line can interface with logic systems operating at TTL levels. The DAT LED repeats the output status of the same name and inverts it, in fact when this one is on due to the phototransistor receiving light on its base (which means an object is present), the output is at low-level, while when there is no light detected, it turns off and DAT output goes to logic level 1.

Note that the choice to pilot the laser diode with a rectangular-shaped wave instead of a continuous signal comes from the necessity to make the sensor immune to lights and environmental disturbances, in fact, if the laser was constantly on, DAT would have (in case of light coming on the phototransistor right after the reflected) a voltage which may be influenced by environmental light, since the phototransistor could be constantly conducting if sufficiently lighted or hit by other light radiations falling within its sensibility spectrum. On the other hand, if we emit light impulses of a certain frequency we can use a receiver module with filter and have it receiving only those impulses, discarding continues light components. In fact, the H2 has an 180 kHz signal filter on its output (2-pin) which allows only signals produced by laser impulses pass.

The use of a bandpass filter on the circuit output discriminates signals, eliminating possible light impulses external to the detection system based on our circuit; besides, it relieves the possible microcontroller interfaced with DAT contact of such duty. Note that the high on-off frequency of the laser does not interfere with the detection since the impulses, although short, are infinitely longer than the short delay introduced by the reflected light hitting the phototransistor. The entire circuit is powered by a somewhat flexible voltage that can range from 2.5 V to 12 V thanks to an integrated switching regulator (labeled U1) which keeps its output to 5 V regardless of load conditions and the voltage on Vcc input compared to ground. Power voltage is filtered locally by the electrolytic capacitor C1. Switching is based on a PT301 integrated circuit, which is a high-efficiency step-up DC/DC compact, equipped with PWM Adaptive Current Mode regulation. Inside it we can find an error amplifier, a ramp generator and a voltage comparator to implement PWM modulation (it compares the ramp signal with the continuous component relegated on the FB pin by the resistive divider R1/R2 and filtered by the capacitor parallel to R1) in addition to a N-channel enhancement-mode MOSFET to pulse on the inductance and to extract PWM’s impulses and its respective driver stage. The internal MOSFET can commute currents up to 300 mA, so if you need to handle higher currents, you can use the auxiliary output (EXT pin) to pilot a higher powered external MOSFET; in this case the output corresponding to the internal MOSFET ‘s drain (LX pin) goes parallel to the external MOSFET’s. The particular thing about the integrated is that it can start up and function with voltages less than 1 V (0.8 V being the minimum) at its input, this makes it ideal for battery-powered applications; the integrated can provide 3.3 V and 100 mA when powered by an alkaline 1.5 V battery and 5 V with 300 mA when powered by a Li-ion cell (1s) or Lipo cell (3,7V). The extremely high efficiency (over 90%) is also guaranteed by the low ON-resistance of the MOSFET and the high commutation frequency of 500 kHz allows to scale down commutation and filter components, that is the L1 inductor and the C3 capacitor (C4 too actually, which is a residual filter at 500 kHz).

This switching functioning is as follows: after the start, through L1 inductance and D1 diode, the integrated receives current (5-pin, Vcc); C3 and C4 start to charge up and, right after that, the integrated starts functioning and its internal circuitry (i.e. the comparator) sends a positive impulse on the MOSFET’s gate causing a short-circuit (ON status) between its drain and its source and therefore all the current flows towards ground; during this interval, the integrated is powered by the voltage coming from C3 and C4.

In the meantime, the inductor charges up and right after that the MOSFET goes into interdiction, then the energy stored in L1 is discharged (since the inductance does not keep it but tends to keep the current right before MOSFET’s interdiction, thus generating an inverted extra voltage with positive polarity on the diode’ anode) through D1 diode, from which it passes on to Vcc, C3 and C4, then to the output of the DC/DC converter to power the % V line (The LED connected in series to R8 resistance signals the presence of output tension of the converter).

Based on the tension coming back on FB pin, the comparator sets the width of the next voltage impulse to send to the MOSFET’s gate, which closes once again the coil in short-circuit for a period that is as longer as the voltage detected by FB is lower (and vice versa) thus charging the inductance again. The cycle starts over as described and goes on till power is cut off.

The integrated continues working once powered up because the CE pin is directly connected to Vcc; if we connect it to ground, on the other hand, everything goes in standby; in this condition, the converter is down and absorbs just 14 µA.

From openstore

Laser sensor board

It can be controlled through logic levels to set the speed and the direction of the rotation of CC brushed motors and stepper motors; outputs have LEDs indicating the rotation direction.

The circuit board we are presenting this time is based on the dual-bridge driver L298N, in a traditionally mounted version in a Multiwatt container with 15 staggered pins; it has two terminal blocks for attaching to DC motors or the coils of a bipolar stepper motor and a terminal block for powering logics and motors. Each of the two output channels of the circuit can provide a maximum current of 2 A, which is enough to drive two 2 A direct current motors or a bipolar stepper motor absorbing 2 A per phase.

Circuit diagram

Now that you have an idea of the circuit performances, let’s get down to it by analyzing the circuit diagram, which is based on the L298N driver by ST: it is a dual H-bridge BJT driver which can be entirely controlled through the EN (enable) and IN (direction) control pins. Each section of this component is made of an NPN bipolar transistor bridge and each bridge is made of two halves in which the BJTs are connected following an almost complementary symmetry, that is the positive-connected transistor is connected to the collector and the bottom one is connected to ground via the emitter (the bridge structure can be seen in picture); therefore, the output is found between the emitter of the positive-connected transistor and the output of the ground-connected transistor.

The transistors bases of each half-bridge are individually piloted by the logic signals coming from the AND ports that have a common input and two separate inputs and are connected to the IC’s IN inputs; the common input is the EN and it activates the bridge so that it can receive the logic signals coming from the INs settings. This configuration allows us to both make use of the IC to pilot four brushed motors in one direction, and then use each half bridge separately, and to use one combined full bridge (by providing the IN control inputs with opposite logic levels) in order to control the rotation of one motor in one direction and the opposite.

In order to better understand the functioning of each single bridge, let’s take a look at the first one, which has 2-pin and 3-pin as outputs (OUT1 e OUT2) and let’s start from the condition in which the respective EN pin (ENA, that is the 6-pin), is at logic zero: in this case the bases of both sides of the bridge are at logical low and transistors are all in interdiction; outputs are in high impedance, this means that they do not conduct in either direction and do not supply current. Now we apply a logical high to the ENA, by applying a voltage of at least 5 V, the outputs of the four ANDs and the respective bridge now will enter into a condition which will depend on the control inputs IN1 (5-pin) and IN2 (7-pin); by applying a high logic level to both of them, the respective half bridge will show a logical high on its output. For instance, if we put 5-pin to logic 1, the positive-connected transistor will conduct and will determine a high voltage level on its output (OUT1), while the ground-connected transistor will be interdicted (because the AND controlling it has its input connected to negated IN1). Under this condition, if we leave IN2 to logical zero, its half bridge will stay with the interdicted upper transistor and the lower one in conduction, while if we also put IN2 to logical high, the OUT2 output will to go to logical high, that means the top transistor will be in conduction and the bottom transistor will be interdicted.

If we invert things, and we leave IN1 to zero and put IN2 to the logical one, OUT1 will show a logical low and OUT2 will go to logical one.

Given the above, we can see that the control of bridge 1 follows Table 1; same goes for the second bridge, so there is no need to repeat it. Moreover, we can see that in order to control a brushed motor and invert its rotation direction we have to connect its terminals between OUT1 and OUT2, then we how to apply, for each direction, a couple of logic levels which are in opposition to the control inputs IN1 and IN2; on the other hand, if we want to control a motor in just one direction, all we need is half a bridge and we are going to apply logical high to the corresponding control input (in this case the motor will be connected between OUT1 or 2 and the ground). By taking a look at this functioning, we can understand that if we are to control a brushed motor that is connected to the outputs of one of the bridges, we can do that by making it spin in one direction or the other one by simply applying opposite voltages at the control inputs, while in order to stop it, we simply have to put said inputs to logic zero: in this case the bridges outputs short-circuit the motor’s terminals with ground, canceling the voltage that the motor itself would tend to produce by spinning idly, therefore charging and applying a slowing action.

Table1

Now that we have explained it how the L298N works, we can see how it’s been employed in our circuit: the IC works in its classic configuration, with a 5 V power source between the 9-pin (logics positive) and 8-pin (power ground and logics ground); the positive side of the power section’s power source (the couple of H-bridges) is Vs and it is connected to the same power source of the motors and the respective protection diodes, labeled Vcc in the circuit diagram. Note that, while voltage is taken directly from the power source terminal block (filtered by C3 capacitor), the logics’ (LVS) can be applied and removed according to the position of the switch of the double deviator SW1; this one allows us to completely turn off the L298N while still leaving voltage on the transistors’ bridges, which however do not absorb current and remain inactive. Having the possibility to deactivate the entire IC by removing the power source allows us to keep the motors power source always connected (power) by operating on a small current such as the one powering the LVS pin. Logics needs are taken care of by the U2 integrated regulator, an SMD 7805 in classic configuration, that is with the input between Vin and GND and the output between Vout and GND; voltage of the latter is well filtered by C1 (minimizing the possible ripple effect due to DC/AC power) and C2 (it filters out voltage impulses due to absorption peaks by the motors), reaches the switch of one section of the double deviator. When this is moved on the lower end (6) the other section is closed between 1 and 2, so that the Vcc input line powers the U2 regulator’s input and Vout powers line 5V with 5 V; on the other hand, when the cursors is on the 4-contact, the other section is closed between 2 and 3, in this case the regulator is not powered and at the same time connection between Vout and 5 V line is interrupted.

Note that, in order to cut the power to the L298N logics we could have simply used a switch connected in series to Vin, but the deviator allows to exclude U2 and to power the circuit with two voltages: Vcc for the motors and 5 V for the logics. This lets us to remotely control the controller from a logic output, for instance through the I/O over the microcontroller and a BC547 transistor.

The 5V line also powers the jumpers with which we can set the enable lines of the two stages (ENA and ENB).  The DS5 LED is connected in parallel to the power unit, and it is powered through the R3 resistance which limits its direct current.

The bridges outputs are each connected to two terminal blocks and each has a couple of LEDs connected in anti-parallel, which current is limited by a resistor (R1 for L1 and L2 and R2 for L3 and L4); as a result, for each output, when the red LED lights on, the output provides voltage with a certain polarity and when it lights on in green it means the polarity is inverted; more exactly, for the first bridge, when OUT2 is positive the diodes light is green, while red corresponds to a positive OUT1 output compared to OUT2. As for the second bridge, the green LED lights on when OUT4 output is positive compared to OUT3 while it lights on in red in the opposite situation. Both outputs have Schottky protection diodes (SMD-diodes M7), protecting them from inverse extra voltages produced by the coils of the motor, one connected to the positive and one to the power negative and placed in such a way that they are in interdiction when functioning normally; diodes conduct only if outputs returns inverse voltage impulses due to the effect of the inductive load which is the electrical motor, and this typically happens when power is cut off or polarity is inverted, that is if we put the enable to logics zero (in which case transistors do not conduct current and isolate the motor, as a consequence there are extra voltages that would discharge on the transistors and damage them if it wasn’t for the diodes). As for the L298N control, we brought IN1, IN2, IN3 and IN4 lines outside through a 4-poles, 2.54-step pin-strip. We remind you that in order to realize an on/off or forward/backward control all you have to do is handle those inputs as shown in Table 1, putting ENA and ENB enables to 5 V (you just have to close the relative jumpers), while if we want to manage not only direction but also speed, we must drive the ENA and ENB inputs with PWM signals. By applying a PWM signal to the enables, we can turn on and off the bridge at the frequency of the rectangular wave of control and for the periods set by the duty cycle of the same PWM; this allows us to regulate mean voltage applied to motors and then to regulate the rotational regimen, maintaining and elevated torque even with low rpm.

That’s get back to the directional control now, which is operated through IN1 and 2 and IN3 and 4: as you can see, if we want to control a breach in this configuration, the logic state of IN1 must be opposite to that of IN2 and IN3 must have an opposite state compared to IN4. Motors must be connected to terminal blocks OUT1-OUT2 and OUT3-OUT4.

Whatever application you are going to use this circuit for, remember that the 2 A indicated as maximum current supplied for each output represents the current limit in the motor, even if the required type needs more than one output; in fact, in the case of the stepper motor the outputs are used in couples, one couple for a coil and one couple for the other one, so since current goes out from one OUT and enters from the other, the 2A limit remains valid. Same goes if we control the brushed motors with velocity control and rotational direction; if we connect four distinct motors there will be no problem because each output will provide 2A max.

You are going to need these notes for the power supply specifics: in fact in the first two cases the IC can absorb (on the bridge side and therefore the outputs side) a maximum of 4 A, while in the second case it will need 2A for each connected motor, therefore four motors with absorb up to 8 A. Re the power: remember that you only have to supply power to the motors, which voltage must not exceed 30 Vcc. For what concerns control inputs (IN1, IN2, IN3, IN4) consider that logic 1 corresponds to a voltage of 4,5÷5,5V and zero corresponds to a voltage of 0÷0,7 V.

From openstore

Motor Driver 2A Dual H-Bridge L298

A 433,92 MHz Receiver that can be paired with a maximum of 10 Motorola TX each with relay outputs that can be set both in monostable or bistable mode.

Although we have had high security encoding for several years, based for instance on rolling-codes, a lot of remote controls and especially those installed long time ago in houses and other places for opening gates, are based on fixed and relatively simple encoding like the MM53200 of former National Semiconductor and the Motorola MC14502x; the latter had two new elements at the time of its introduction, that were the high (for the times) number of combinations allowed (19,683) and the three-state encoding (each encoding input of the encoder and of the decoder would allow three logic levels and required special three-state dip-switches).

As it happened for the MM53200, the Motorola encoder has also almost disappeared from the market, giving a hard time to those who had installed a remote control and had to look for a hand transmitter that could replace a broken or old controller. This is why we thought we could help by designing and proposing, in this post, a receiver for Motorola encoded radio controllers, which can be used both for replacing broken controllers or controllers that cannot be found on the market, and to incorporate in only one circuit the receiver unit, the decoding and a memory that allows the receiver to respond not only to a transmitter, but to more than one; this is useful in case more people who have different transmitters must access a single entrance, without sharing the code, so without knowing each other’s codes. It is also practical because it allows, for instance, to access the entrance even if one’s transmitters is lost, thanks to a spare previously coupled radio controller.

Another reason for proposing our receiver is that it can learn the code directly from a transmission outputted by the circuit’s TX, which allows limiting encumbrance of the receiver because you don’t need the 12 poles dip-switches requested by the manual setting, and to couple the receiver to the transmitter quickly and without any errors.

Circuit diagram

Now that we have established this, let’s take a look at the circuit diagram of the receiver, which is based on a PIC16F688 microcontroller and a hybrid radio receiver module tuned on 433,92 MHz; the U2 module contains the radio part of the circuit and it is a specific receiver labeled AC-RX2 and produced by Aurel, complete with an amplifier for the signal coming from the antenna (which provides a sensitivity of -106 dB), a stage of super regenerative harmony tuned on 433,92 MHz calibrated by the factory and equipped with an RF filter (the antenna filter is used to increase selectivity, which is low in super regenerative, and to demodulate amplitude). The AC-RX2 is also equipped with a comparator that squares the digital signal (at TTL-level) coming out of 14-pin and a LF amplifier for the signal coming out of the AM demodulator.

As for the microcontroller, it is an 8-bit microcontroller with a flash program memory and the firmware on it, right after being powered on and after finishing the Power On Reset (phase signal by a sequence of 5 flashes of the green LED that will indicate a correct boot) it initializes the I/O’s setting RB0 and RA6 as outputs, which will be used to control, respectively, the NPN T2 transistor driving the control relay of the channel 1 load and T1, which drives OUT2’s relay.

Each relay is excited by the saturation state of the respective transistor, which is in turn polarized following the microcontroller line drive in it when this line goes to logical high (R1 limits base current of T1 in order to avoid damages to the base-emitter junction and R2 does the same with T2). In parallel to the coil of each relay there is a production diode (D3 for RL1 and D2 for RL2), which function is to short-circuit the inverted extra tension generated by the coil when the transistor, in interdiction, interrupts the current flow during its saturation phase; if it wasn’t for the diode, voltage would close on the base-collector junction of the BJT and would damage it after a limited number of commutations by the transistor.

Still during initialization, the microcontroller sets RA4 line as input for acquiring data coming from AC-RX2, RB4 and RB5 as inputs (with internal pull-up activated by firmware) to read the state of the dip-switches (these lines have also an internal pull-up) and RB6, RB7 for reading the state of P1 keys (in order to launch the code learning paired with channel 1) and P2 (pressing this key launches code learning for channel 2); these last I/O lines have their internal pull-up to.

Continuing with initialization, the microcontroller sets RB1, RB2, RB3 as dedicated outputs, respectively, for controlling the LD3 signal LED (green, indicating the passages of the self-learning procedure and normal functioning), LD1, which indicates the activity of channel 1, and LD2 that does the same for channel 2.

DS1 dip-switches are used to set the functioning mode we desire for each channel; to be precise, dip1 (the one read by the microcontroller’s RB4) allows to set OUT1 while dip2 (the one read by RB5) sets the activity for output OUT2. A closed dip activates the bistable functioning (that is, for each valid code received, the corresponding relay inverts its state), while an open dip means monostable functioning (for each valid code received, the corresponding relay is excited then goes down again after releasing the key of the transmitter).

R4 and R5 trimmers you see in the circuit diagram will be used in future developments and are available for whoever wants to modify the firmware in order to, for instance, implement a delay in the release of the relay in monostable mode; this can be done by activating a timer and loading, as period, the equivalent of what the A/D converter contained in PIC16F688 reads from the scanned trimmer pins.

The two red LEDs of the circuit follows the state of outputs during functioning; specifically, LD1 lights on when OUT1 relay is excited and LD2 lights on when OUT2 relay is excited.

The circuit is completed by the power unit, which starts from points + PWR and – PWR (the power terminal block) , crosses D1 diode (which protects from damages caused by inversion of polarity) and reaches the 3-terminal integrated regulator U1, which input is filtered by C1 and C2, reducing a possible power voltage flickering (C2) and RF disturbances and impulsive disturbances catch by the power wiring (C1).  C3 and C4 do the same job for the regulators output.

Functioning

Now we can explain how the receiver works: when powering the circuit, and firmware, once completed the I/O initialization, makes the LD2 flash five times, in order to indicate a correct boot and normal functioning, that is receiver for radio control (corresponding to the execution of the command provided remotely); then the Main goes in loop to verify if there is a level variation on 12-pin and 13-pin (key state variation). A dedicated routine periodically checks the state of 2-pin, that is the arrival of data from the AC-RX2; when we press one of the keys on the transmitter, the RF signal irradiated by it reaches the receiving antenna of the AC-RX2 module, which demodulates the data component and sends it to the 13-pin to make it available for the microcontroller, which reads it from its RA5 line. The micro decodes the code corresponding to the pressed key on the remote (although the firmware also provides a routine to automatically learn the base code of the same without setting dip-switches) and operates this way; the microcontroller picks inputs at TTL level, puts them in the RAM and analyzes them via a dedicated firmware routine that first and foremost tells the signal compatible with the Motorola encoding format apart from the many signals found in the ether, therefore, in case of a positive, it checks if the code is one of those memorized during the self-learning phase, in case of a negative, it eliminates data from the RAM and prepares for a new analysis.

You will see later how to pair the transmitter and the circuit, making use of self-learning; for the moment, just know that the firmware expects a maximum of 10 codes to be learned, even from different transmitters. In fact, each code is fully memorized, that is all its three-state 9 bits are saved into nine EEPROM bytes by the microcontroller; we are using nine bytes because it’s the most immediate solution, given that each address line (encoding) of Motorola MC145026 encoder allows for three logical conditions (1, 0 and open), it is not possible to turn them into binary bits and directly save them in a binary memory.

Now, let’s see what happens when the received signal contains one of the known codes which are saved in the PIC’s EEPROM, in this case, we can apply the dedicated relay handling routine, which determines different actions based on the functioning mode, whether monostable or bistable; we remind you that mode setting depends on the dip-switches which are read by the firmware when it has to control the outputs. Therefore, if the received signal contains one of the codes in the EEPROM, the firmware starts the handling routine of the correspondent relay output, which is different depending on the respective dip-switch being open or closed. Please note that functioning mode of outputs can also be modified during functioning, in fact, we don’t need to turn off the circuit and then on again, thanks to the fact that the dip-switch of DS1 is read right when one of the relays must be activated.

We remind you that in bistable mode, the relay changes its condition anytime the microcontroller recognizes a valid code, while in monostable mode, the relay goes to logical high when it receives a valid code and goes back to standby when the key corresponding to the code is released, that is once the activating signal goes off: in short, the relays follows the key. If transmission ends but at the same time a new transmission is received by another radio controller that has been paired with the receiver (i.e., the code belongs to one of the 10 learned codes) within the timeout frame allowed by the firmware, the microcontroller considers the transmission as if it was never interrupted. If the code from another TX comes when the relay is active because it is receiving the transmission from another valid transmitter, the conditions is no longer valid because the second transmitter interferes with the signal from the first one and the radio receiver will demodulate the overlapping of the two data streams; as a result, the microcontroller will think that activation signal is over and will cause a relay to go low.

Learning procedure

Let’s now take a look at how to pair transmitters and circuits: first things first, we need to press and hold the key corresponding the channel we wish to save in memory (P1 for channel OUT1 and P2 for channel OUT2). The red LED for the output (LD1 for OUT1 and LD2 for OUT2) will light on to signal self-learning mode. After that, we need to press the radio controller key we wish to learn and wait for the LED to blink, this indicates that the operation was successful.

If the LED light remains fixed, it means that code memory is full or the received code is not valid.

As for code erasing, please note that our receiver can only erase memory relative to a single output channel, but not a single code of a radio controller. In order to erase the memory of one channel we need to power the circuit by pressing and holding the key relative to the channel we want to erase; P1 for channel 1 (OUT1) or P2 for channel 2 (OUT2); then we have to release the key when the green LED (LD3) stays on for 2 seconds in order to indicate a successful elimination of the memory bank relative to the chosen channel. The green LED will flash 5 times when exiting your erasure procedure and the receiver will go back to normal functioning.

All the signals provided by the circuit LED both during normal functioning that during learning and cancellation procedure are listed in Table 1.

Table1

To power the receiver we need 12÷14 Vcc and an 80 mA direct current.

As for usage, remember that outputs must commute a current of 3 A each, in circuits powered with a maximum of 125 Vca and 160 Vcc; this means that if you have to commute loads connected in functioning circuits with the 230 Vca power grid you will have to use servo-relays fit for that voltage, driving the coil by switching the relays on our board. If you use 12 V servo-relays, connect one terminal of the coil of the servo-relay to the ground and the other one to the NC contact of the receiver output that you are going to use for the control, then connect the No to the + terminal of PWR terminal block. This way, when the relay is activated it applies voltage on the servo-relay. In order to prevent premature wear of the contacts, it is recommended to parallel-connect the servo-relay coil to a 1N4007 diode in anti-parallel: the diode will then have the anode connected to ground and the cathode on the positive terminal, therefore on the NO output.

From openstore

Two-channel receiver at 433.92 MHz Motorola decoding

TX 1 CHANNEL 433 MHz

TX 2 MOTOROLA CHANNELS

Trasmettitore 433 MHz 4 canali codifica 5026

A Bluetooth enabled remote that will help you control one or more IR-controlled electric payloads.

In this post, we are going to present a project for emulating an IR remote control composed of a RandA board (an Arduino that has connectors to interface with Raspberry Pi on one side and connectors for Arduino shield on the other) and a dedicated shield (ArdIR), that allows to control house appliances by reproducing the signals emitted by respective controllers. The peculiarity of this project is the possibility to control them remotely, via the internet, thanks to a dedicated web interface that can be accessed via the browser of devices connecting to it. Given that we had used an Arduino shield for that project, we thought it could be a good idea to use it again by reviewing the entire project from an Arduino perspective, that is by taking off Raspberry Pi and RandA and applying the shield directly to an Arduino Uno board. And…voilà! In these pages we will see how to control the ArdIR shield through a Bluetooth connection, therefore a close range one; this means that the “remote” controlling device will have to operate inside the same building of the system’s, at a distance not over a few meters, especially if there are big walls interposed between transmitter and receiver. This requirement may appear as a limitation and may lead to asking why did we choose this system. Well, if one needs to manage some devices inside one’ house although out of line of sight of classic IR remotes (e.g. if you want to listen to the music on your Hi-Fi which is in another room, and you want to be able to control volume, track, etc.), Bluetooth communication may be the most convenient because it doesn’t need an active LAN (with router and Wi-Fi to connect to mobile devices); connection between devices is direct (point-to-point), provided that each is equipped with Bluetooth interface. This is (almost) always true nowadays for tablets and smartphones, which in this project act as controlling devices; in the controlled device, that is the system composed of Arduino and the ArdIR shield, this is not the case because generally, Arduino doesn’t have this interface. We opted for a shield available as a kit (code FT1032M).

In Figure we can see a recap of our Bluetooth remote controller; the user can utilize any mobile device (equipped with Bluetooth interface), through a dedicated app that we are going to analyze below, to send the desired commands; these will be radio-transferred to the Bluetooth shield, thus making them available to Arduino which, through the dedicated sketch, will manage the ArdIR shield to emit the infrared signal direct toward the device to be controlled.

On a logical level, the figure shows, on the other hand, the hardware/software “Andes” involved in the data exchange between the devices.

Now that we have established the scenario, that takes a look at the application software (app and sketch) responsible for the functioning of the respective parts. Ask for a detailed description of the two shields (and to also get to know their pros and cons) please see this post (bluetooth shield and IR shield).

The ArdirApp application

This application has been developed for Android systems, therefore it can be installed on devices based on this platform, starting from version 4.1 (jellybean). The development environment employed is Android Studio, recently sponsored by Google as official software for developing Android application instead of Eclipse.

From a user perspective, our app needs two phases to be handled:

1. Research and connection to the target Bluetooth device, i.e. shield FT1032M;
2. Selection of the channel to be activated, for transmitting the code to the shield FT1032M.

from a programmer perspective, in order to execute the bow, we need to structure a program composed (at least) of the main class, in charge of handling starting activities (graphics and resources initialization) and events management (callback of the user interface buttons) that we have called “MainActivity”. Bluetooth handling, on the other hand, is assigned to a separate class called “bt_Clientclass” in order to keep the code clean and easily maintainable.

The logic flow of “MainActivity”  behavior is outlined in the figure; at launch, after assigning and initializing the various resources, the program verifies the presence of the Bluetooth interface; if the interface is not enabled, the program asks the user to do so. If the user denies, or if said interface is not detected on the device we are using, the program will terminate. ViceVersa, once the interface is enabled the program will allow access to the list of active Bluetooth devices nearby Colin and the user will have to select the one he desires common in this case, we are selecting the RN42 module of the Bluetooth shield referring to the system the ArdIR is connected to. After that, the program will learn the physical address (MAC) of said device and will be able to connect through the connect() method defined in the “bt_Clientclass” class.

Once the connection with the Bluetooth shield is established, our app will wait for the user to select one of the available channels on the graphic interface, which will then be transmitted via IR from the ArdIR shield. When this happens, the message formed by a precise number sequence is created, which contains the code for the children channel, at the same time we call the write() method from  “bt_Clientclass” class, which is in charge of transmitting said data via Bluetooth.

Once done that, the program is ready to handle a subsequent command by the user and will be listening to possible messages returned by the remote Bluetooth device. In our case (similarly to what would happen on the web controlled version) this data can come from Arduino which, after receiving and processing the command, will activate the ArdIR shield and transmitted back the result of the operation via Bluetooth using character strings (“OK”, “Fail” or the temperature value requested). Therefore, this strings will be received by the app directly displayed on the user interface.

Please note that the message reading thread is separated from the main program flow: this way, we can avoid a crash if the return message is not received for some reasons. To be precise, we are using an android mechanism employed for exchanging data between different threads, that is the message queue (MessageQueue): specifically, we have allocated a handler-type object in MainActivity and then transmitted its reference to “bt_Clientclass” class (when the object is created); the latter will use it in order to transmit messages containing information and data coming from Bluetooth, thus automatically triggering the handler method call handleMessage() and making the message available to MainActivity that will finally put it on the display.

Let’s now analyze functionality of class “bt_Clientclass” that manages the Bluetooth, dedication to Arduino by configuration of the device (as the name itself says) as client peripheral, while the Arduino side will act as server (specifically, the base architecture has been modified from the “BluetoothChat” project, a demo on Bluetooth communication available on the website www.developer.android.com). The logic diagram for functioning can be seen in the figure; since this is a “service” class to the main application, we illustrated only the interface methods that refers to the flow diagram shown in previously.

By calling connect() method from MainActivity we establish Bluetooth communication which, in Android, once identified the device to connect to (and their relative address), is done in two steps:

1. A communication channel (socket) to the server is opened;
2. Connection to the socket.

In the first step, we try to establish a connection to the device relative to the specified address, using the createRfcommSocketToServiceRecord() method of “android.bluetooth.BluetoothDevice” class; said method requires to transmit a universally unique identifier (UUID), i.e. a unique 128-bit number for each device in the Bluetooth network we are working in. In our case, in order to connect to the RN-42 module, we use a preset “generic” UUID. As the name implies, the China we are asking to open is an RFCOMM channel (a communication protocol “simulating” an RS232 serial port), which the Bluetooth profile SPP (Serial Port Profile) is based on. This type of protocol is one of the most commonly used for transmitting data between devices using Bluetooth, says it is used by many applications that were designed to make use of the serial port for communication and it is supported by all the main operating systems on both mobile and non-mobile devices.

Back to our program, after successfully creating and opening the socket, we call the connect() method in order to activate the connection to the server; even if this fails, communication is established and ready to exchange data between the parts. To do so, we associate to objects of types “InputStream” and “OutputStream” to the socket on which we will work in order to read and write data.

If we take a look at the code, we can notice these procedures are executed within two nested classes, called “ConnectThread” and “ConnectedThread”. These classes, which extends the Thread class, have been indeed used to handle connection and communication stages within the two respective threats, which executions are independent of that of the main program: this way we can avoid crashes in case of connection problems or communication problems with this Bluetooth server. Moreover, because of this we can notice how, in the flow diagram, once connection stage is over the code stays “hibernated” waiting to receive data from the Bluetooth, on the “InputStream” object; given that this is executed we’ve seen a thread, this does not compromise the main program functioning. Therefore, we can say that data reception logics is handled by a process running in background, asynchronously and independently from the main application. When the server (managed by Arduino) transmits the data string, it will be recouped old the code until it receives the end-of-queue character. Now the process will use the handler provided by MainActivity in order to transmute the receipt string, in the following manner:

• creation of a message by: obtainMessage() and passing the data string;
• from the instance of the message just created, SendToTarget() method is called; this will trigger, as mentioned above, activation of its “counterpart” (the handleMessage()) of the handler, that will make the data available in the MainActivity class since it is implemented within that class.

On the other hand, in order to transmit data to Arduino, MainActivity only has to call the bt_write() method, passing as argument the data vector we wish to send; this will be then transmitted to the Bluetooth peripheral through the write() method of the previously initialized “OutputStream” object.

Sketch ArdIR_BT

On the Arduino side, as mentioned above, we have the ArdIR shield that is handled thanks to a firmware largely derived by the ArdIR.ino sketch, also explained in the article relative to the above-mentioned shield; for this reason, we will focus our attention on the changes made from that sketch.

This time, the Arduino serial port is connected to the RN42 module of the Bluetooth shield, therefore, we have to manage communication with shield accordingly, with a communication speed of 115,200 Bauds, as well as a possible initialization stage. For this reason, the serial interface is probably initialized within the setup() function of the shield, then only “minimal” info is transmitted to the RN42 in order for it to work correctly, that is by setting it on SM0 mode (see the module manual for more info) so that it will act as server in communication towards Bluetooth devices.

From a functional perspective also, the program perfectly recreates the behavior of the original “ArdIR.ino”; its state diagram is illustrated in Figure.

Let’s briefly recap the function and logic: we start from the waiting stage, in which both LEDs of the shield are off, and we wait for an action to happen, which can be:

• Pressure of P1 key on the shield, in which case code acquisition stage of one channel of the remote control is activated; this way the key (channel) activated by the app is associated with the infrared code that we want to transmit to the receiver (TV set, etc.); below, we will describe the practical operations to carry on;
• Pressure of P2 key on the shield; acquisition and transmission of the first channel is managed “locally”, that is without help from the remote Bluetooth device;
• Reception of a channel number from the Bluetooth module (therefore from a smartphone/tablet equipped with the app mentioned above); this is the “normal” functioning stage of the system, in this case, IR transmission of the code associated with the channel of the previously acquired remote control is activated.

From theory to practice

Now, let’s take care of preparing and activating our system; to do this, we need:

• An Arduino Uno board or equivalent (e.g. Fishino Uno);
• An ArdIR shield (FT1219K);
• A Bluetooth shield (FT1032M);
• A smartphone or tablet with Android OS (version 4.1 or higher), of course complete with a Bluetooth interface.

Before connecting Arduino to the shields, we have to upload the sketch, since this operation is executed through the lines of the hardware serial port (D0 and D1), which are seen used by the Bluetooth shield: if this was already inserted, we would, therefore, have a conflict which will make programming impossible. On the Bluetooth shield we also have to disconnect, perhaps by cutting it off with an X-Acto knife, the line going from a fourth signal of the Arduino connector to PIO9 pin of the RN42 module, since this interferes with the I²C boss used by Arduino to interface with the EEPROM of the ArdIR shield. In the same illustration, we can also notice the setting of the fort dip-switches: AUTO” must be ON, while the others must be OFF.

As for the ArdIR shield, if you have an Arduino Uno board revision 1 or 2, you have to connect signals a four and a five through two “flying” wires respectively to SDA and SCL. The figure shows the complete system of these “bridges” on the ArduIR shield. Please note, finally, that the Bluetooth shield has to be mounted under ArdIR.

Once your system is “assembled”, you can power Arduino through the USB plug or through an external power source. Immediately you will see the LD1 LED (on ArdIR) flashing three times to indicate that the system is ready to be used. Besides, on the Bluetooth shield, you are going to notice the continued flashing at around 1 Hz of the red LED  (also called LD1) to indicate that it is waiting to be detected by another Bluetooth device.

So, let’s also install and activate “ArdirApp” in our Android smartphone of choice; at startup you will be asked, if you haven’t done it already, to activate the devices Bluetooth peripheral: of course you are going to confirm it. Then you will be presented with the screen you can see in figure, where the “not connected” label under the title indicates that we still have to establish a connection with the module on Arduino. Let’s enter the menu then (magnifier icon next to the title) which shows the list with all the previously “paired” devices. First time, therefore, you will not see yours, so we are going to activate the “scan for devices” command; this way, the Bluetooth shield voice should also appear, reporting name and “MAC” address of the RN-42 module, e.g.:

FireFly-E6CB

00:06:66:4F:E6:CB

Where “FireFly” is the local name aside by the microchip to its Bluetooth modules by Roving Networks (the module name can also be changed; whoever is interested in doing that can reference to the dedicated documentation in the module).

By selecting that voice on the manual, the program will try to establish a connection (pairing) with the module; the first time you will be asked for authentication via passkey that is “1234” by default. If the operation is successful, you will see the centers “connected to (module name)” appearing in the title.

We can then proceed with learning one code from the remote control, for instance, the mute button on the TV, that we will assign to channel 1 on our app.

Note: if the learning the phase of the ArdIR shield had already been implemented, perhaps through the webpage (using RandA), said procedure is no more necessary since all the codes acquired by the remote control will be written in the EEPROM memory of ArdIR and not therefore permanently safe (unless you want to overwrite them).

After making sure that the JP1 bridge on the ArdIR shield is NOT inserted (otherwise the EEPROM will be protected from riding), we press P1 enter in acquisition mode from the remote control, the red LD1 Led of ArdIR will start blinking, communicating that it is waiting for one of the channels on the app screen to be activated; let’s select Channel 1. The LED will be fixed on to inform us that we have to activate the volume reset key on the remote control (after “pointing” towards the infrared receiver IR1 at about 10 cm) in order to transmit the code to be acquired. Once Don that, the green LED shoot light on for five seconds in order to communicate the new code has been learned successfully. We can then try it out, by pointing the infrared LEDs of ArdIR tour the TV set and making sure that, by pressing the “Channel 1” key on the smartphone, televisions volume is muted.

We can, therefore, continue memorizing other commands from other channels that, as suggested on the HTML version, can be increased at will (compatible with the displaying capacity of the mobile phone screen), as discussed in the dedicated box in this article.

This time too, we have the possibility to poll the DS18B20 sensor mounted on ArdIR in order to read ambient temperature, by clicking on the “Vis. Temp” key. Remind that, at the first polling, the return temperature will be 85°C (default reading the value of DS18B20 sensor) since the are no conversion commands previously executed.

From openstore

Arduino UNO R3

ArdIR Shield – To assemble

Shield Bluetooth with RN-42

Supplied with a robust chassis (made of plastics) and with three stepper motors, it is provided with a 9,000 RPM electro-spindle, to which it is possible to apply different kinds of milling parts, for the purpose of working wood, plastics, synthetic resins, and for carrying out small engravings on aluminum.

It is not the first time that we deal with numerical control machines for domestic use, that are suitable for milling or for fine engraving, for the creation of mechanical parts, and objects having different shapes – for the purposes of 3D printing and subtractive manufacturing. We did that already when we showed you one of the many transformations of our 3Drag printer, at that time turned into a CNC milling machine, used for the purpose of engraving printed circuit boards and equipped with a Proxxon electro-spindle. In the meantime, we had the chance to try other machines, and in these pages, we will show you a CNC machine that is available in its assembly kit, and that stands out because of the excellent value for money. That was achieved also because of the fact that compact PVC was used for the chassis. The machine has been designed mainly for the purpose of engraving PCBs and plates (such as those for mailboxes, intercoms, doorbells) built it is possible to use it in order to work with wood, plastics (even the POM ones); it is also possible to engrave aluminium plates (at a low depth), but without overdoing it.

As with most of the CNC machines, even this one is supplied with a control board for the three axes and interfacing the parallel port, so that it may be driven by means of software such as the well-known Mach 3 (or the more recent Mach4). The latter is a software that converts the G-Code in pulses, that are directly produced on the parallel port. This could be seen as a problem, because of the port disappearing on the modern PCs, but we already thought to a solution that we will describe in the next installment, and that will allow you to drive it directly from USB (and therefore via all the modern computers).

Someone might object that it should be enough to use a USB/parallel adapter (of those that are commonly found for sale), but it is not as easy as it seems. In fact, the problem is twofold: first of all, since the data is sent in a virtual parallel, it would then be converted to parallel form with a certain delay, or worse, with unequal delays that would bring to movements on the three axes that are not perfectly synchronized. The second reason is that many programs for the CNC control do not natively consider managing via USB ports (but by means of their plug-ins, they do).

Our proposal is instead the one of a hardware that, starting from the USB and taking advantage of open-source software, enables the reconstruction (on the machine) of the command pulses for the CNC control board, thus fixing the temporal inconsistencies of the common USB/parallel adapters.

The machine

Let’s start immediately with an overview concerning this new amateur machine tool, that is composed of very robust and accurate mechanism, of a chassis (that enables a working space of as much as 200x180x60 mm), of an electro-spindle and of an electronic board managing the whole; the power is supplied by a switching power supply as for the board (and therefore for the motors), and by a transformer, followed by a Graetz bridge as for the electro-spindle (therefore the voltage is an unregulated one).

The board (that is powered by the dedicated AC/DC switching power supply) commands the three stepper motors of the NEMA17 kind (200 steps/rev) and by means of a relay it switches the electro-spindle  on and off, at the command of the program running on the PC; it is provided with a parallel interface, whose pins are directly connected to the command lines of the three motors’ drivers, therefore that’s EN (enable), STEP (pulses) and DIR (direction). Each one of the three driver channels for stepper-motor enables the functioning of the microstep mode, that is to say, it enables fractional steps; thus it is possible to make the corresponding motor advance – when the pulse on the corresponding STEP line arrives – by 1/2, 1/8 or 1/16 of a revolution. Considering the motor’s resolution, this means it is possible to advance the corresponding axis by 400, 1,600 or 3,200 step per revolution.

The mechanism is a particularly simple one, yet the mechanical parts are robust ones, and consist of side (base sides and side plates) and back (base) walls, on which the plate (where the workpiece will be placed) and the rectified bars (having a 12 mm diameter, they act as rail for the head that supports and moves the electro-spindle) will be applied. The electro-spindle moves on 2 axes: y (side) and z (vertical); both are motorized by means of a stepper motor that – by means of an aluminum joint having a Ø5 mm connection for a drive shaft – makes an endless screw rotate. In the latter, one of the stirrups that impose the movement (that is facilitated by recirculating ball sleeves, having a 12 mm internal diameter) has been push-fitted.

The coupling takes advantage of a tested and refined solution, that enables the automatic reloading, thanks to the preload springs, that have to be calibrated during the assembly. The support for the electro-spindle has a collar having a 52 mm diameter.

The side plates of the mechanism are 15 mm thick, while the moveable plate that supports the working piece measures 240×190 mm and has been made of compact PVC as well; it is moved back and forth by means of the usual stepper motor that drives (via an aluminium joint having a Ø5 mm connection for a drive shaft) an endless screw, coupled to the undercarriage, thanks to the abovesaid mechanism for restoring the play.

The tool holder head and the plate’s bogie both move by sliding on two steel rectified bars having a 12 mm diameter and by means of the usual linear bearings (12 mm recirculating ball bushings).

The threaded rods that make up the endless screws are M8s and have a 1.25 mm thread step, that (still considering the discussion made before, on the subject of the electronics driving the stepper motors) enables a resolution, as for the movement of both axes, of 1.25/200 = 0.00625 mm, corresponding to 6.25 thousandths of a mm! If the microstep mode is chosen, it further grows, but let’s say that we are at values that are more than suitable for any kind of manufacturing.

Please notice that, because of the limited size of the machine, the control board and the power supplies are not applied to the chassis (since their encumbrance would be such to require a very big box) but they must be placed in a box aside, and have to be connected to the motors and to the electro-spindle, by means of electric cables having a suitable length.

Building the mechanics

Well, we believe we made this CNC attractive enough: therefore, if you decided to create it, we will guide you, step by step, and starting from the assembly of the mechanical parts. We used plastics for the chassis, which helps in the realization since it is possible to fix some parts simply by slotting them in (which occurs in factories, as for the recirculating ball bushings) or by means of screws.

The figure shows the whole of the parts that make up the CNC mechanics. Once you have the material, the first thing to do is to create the coupling groups with extension recovery, by taking the 3 parts (plates) that in figure have been identified by means of the number 14, and by inserting two plugs in each one of them (with the help of a hammer), each plug must have the head towards the M8 nut, as shown in the second figure .

Once this has been done, you will have to fix one of the plates that has been so prepared on the element n° 19, by means of two M4x25 TCEI screws, 2 M4 nuts, and as many M4 toothed washers. The same should be done with the elements n° 11 and n° 9, and please pay attention to the fact that with the latter you will have to use 2 M4x30 TCEI screws. You will find yourself in the situation shown in figure, by inserting a spring on each plug.

The elements n° 15 will have to be inserted into the plug’s ends and then tightened along with the threaded rods. Please screw the shortest one for a pair of cm in the nut of the tool holder head (detail n° 9), by keeping the shortest and non-threaded rod’s end upwards. Please press the element n° 15 on the springs, so that the plugs emerge of about 2 mm, then please continue to tighten the threaded rod, so to make it enter in the second nut as well, and as shown in the picture. The springs are needed in order to avoid the backlash between the nut and the threaded rod, so to guarantee an extremely accurate realization, even in the most limited movements.

After having inserted the threaded rod in both nuts, you will need to verify that it might still rotate without excessive efforts, so to avoid step losses from the corresponding motor. If needed, please reduce the pressure on the springs.

You will now have to apply some fine oil on the two nuts, so to improve the rod sliding.

Please follow the same procedure when inserting the 315 mm threaded rod in the element n° 11, and the 305 mm one in the element n° 19, so to reach the situation shown in figure, in which all the three play recovery systems have been mounted. At this stage it is possible to mount the group for the guide and the activation of the sliding plate that will host the workpiece: we will start by fixing a stepper motor on the rectified bar n° 5 (back one), by means of the specific M3x12 bolts and then with two 305 mm rectified bars via two M6x20 TCEI screws, but without tightening them to the end, so to allow the alignment at a later time.

Please mount a joint on the motor’s crankpin, and temporarily fix it with a grub screw, so that it does not move, and then please insert the bushings that are mounted on the element n° 18 in the rectified bars, and orient them, after having oiled (with the usual fine oil) the internal side of the bushing, in correspondence with the the microspheres. Please notice that all the CNC bushings have to be oiled before being inserted on the rectified bars, so to facilitate the sliding. Please add the element n° 19 and direct it and continue by laterally fixing the two side walls n° 2 (with the rings pointed towards the motor) to the rectified bar n° 5, and use the dedicated screws, but without tightening them completely. Please then continue by inserting a bearing at the end of the threaded rod and by applying the opposite side (detail n° 4) with the bearing (in which the end of the threaded rod will be inserted) and pointed outwards. Please tighten the screws without fastening them completely and then align all the parts and gradually tighten all the fixing screws, and until the end.

You will now have to align the ends of the two rectified bars with the holes of the front rectified bar, and then to insert 2 M6x20 TCEI screws. Please definitively fix the rectified bars, by gradually tightening the corresponding screws, so to reach the situation shown in the picture.

All that is left to do is to tighten the M5 nut of the threaded rod, by clamping the latter (please place a rubber sheet between them, so to prevent ruining it) and by tightening the end from the external side; when fastening the latter please tighten it until you feel that the bearing is getting fixed, then please loosen it so to make it free to rotate, otherwise it would be pointless.

Now, please place the surface n° 3 (with the holes pointed downwards) on the rectified bars n° 18 and 19 that compose the X axis’ bogie, and align the surface’s holes with those found on the bogie’s rectified bars, and then please fix everything by means of 10 2,8×18 self-threading screws: the base of the plate is ready.

Let’s move on now to the assembly of the pillars that will support the tool holder head: please get the element n° 6 and apply the two 305 mm rectified bars by means of 2 M6x20 TCEI screws, whose points will have to be manually prepared, and then apply the detail n° 12 by making it fit the bushings that have been placed on the rectified bars, and by respecting the orientation shown in figure.

Please also apply the element n° 11, completed with the spiral (please oil the bushings beforehand), and direct it so that the plates’ fixing holes are all pointing the same side. Please insert a bearing at the end of the threaded rod. Now get the other pillar and faster it with the screws that have been supplied (on the rectified bars), after the head of the threaded rod has been inserted in the dedicated hole; please remember to tighten the nut of the threaded rod (with the usual precaution of placing some rubber in between, before tightening the bar with the pliers) for as much as it is needed to leave the bearing free to rotate. Thus you will have prepared the strut and its mechanism.

Please fit a joint on the crankpin of a stepper motor and fix it (by means of the 2 grub screws) at a distance of 7 mm from the body of the motor, and then mount the motor on the right side plate, by means of 4 M3x20 TCEI screws, each one completed with a 3×6 plain washer, and by directing the corresponding connector towards the base of the side plate (the largest side). Please then tighten the side plate by means of the screws that have been supplied.

Now, please fix the plate n° 1 on the back side of the side plates, by means of four 2.8×24 self-tapping screws, and then the plate n° 8 on the Y axis’ bogie, by means of 8 2.8×18 self-tapping screws, and please direct the shortest side (the one with the holes that are closer to the edge) downwards.

You may now assemble the complex that will support the tool holder head and the corresponding movement mechanism on the Z axis; as a first thing please apply the last stepper motor to the element n° 16 and tighten the aluminum joint on the drive shaft. Please then make the bushings that have been mounted on the detail n° 10 (after having oiled them) to slide on the rectified bars, and direct the element as shown in the figure, and add the element n° 9 and the last bearing on the threaded bar.

Please apply the plate n° 17 to the rectified bars by means of M6x20 TCEI screws, and point the bearing outwards and the four holes on the same side of those on the motor plate, so to obtain a result as the one in the picture.

You will then obtain a result such as the one in the figure, that is to say, the strut complex that you will have to apply to the lower part of the machine, by means of the specific screws.

Please place the strut on the chassis’ base and fix it in the most backward position possible, by means of 4 M8x35 TE screws and completed with 2 8×16 plain washers and M8 nut, in such a position to keep the side plates at the same distance from the bottom of the base: with this operation you will have completed the mechanics of your CNC.

All that is left is to assemble the electro-spindle found in the kit or to choose to mount a different electric tool, as long as it is supplied with a round support beam (having a 52 mm diameter) with which to fix it.

If you will be using the one of the kit, please get the collet chuck from the box, and insert it in the specific hole that has been obtained in the clamping ring of the mandrel (please place it with the side having the hole towards the screw cap), then tighten the ring itself until you reach a situation as the one in figure. Please place the electro-spindle in the collar of the tool holder head and fix it by means of the specific screws; you will complete the plate with the stirrups for the workpiece placement.

Wiring of the electric and electronic sections

Once the mechanism has been completed, we have to move on to the wiring. The first operation to be carried out consists in inserting in each stepper motor’s connector the corresponding connecting cable (intended to be self-built), one that has a connector at each end: one for the motor and the other one for the 3-axes controller board. The connectors are of the AMP MODU I type or terminal boxes ending with the said connection. As for the wiring, please stick to the figure, that shows the connections for all the elements of the CNC machine. The power supply’s 220 Vca input and the transformer’s primary input must be powered in parallel, by means of a power cord ending with a network plug. The electro-spindle must be powered by making the positive of the power line coming from the bridge rectifier pass through the relay’s switch, the relay’s coil will be driven by a specific couple of pins that are highlighted by the yellow circle.

The figure shows the machine completed with the electric connections, and whose cables are all in the back, so to prevent them from being a hindrance. The electronics and the power sources must all be placed far from the CNC (please, consequently choose the length of the cables) and protected, so to prevent that shavings and scraps from metalwork may reach them: that would cause dangerous short circuits and the electronics or the DC/DC would be quickly put out of order.

The 3-axes controller board for the machine is already set by default for the control of bipolar stepper motors; anyway, you may change the settings at leisure, by means of a series of dip-switches for each of the three drivers. As a first thing, let’s see the settings for the possible microstep mode: by means of the DIPs 1 and 2, it is possible to set the motors’ resolution (full step, 1/2 step, 1/8 step and 1/16 step), as shown in Table 1, so to advance the axes’ motors of a step fraction, in correspondence for each pulse coming on STEP from the computer.

Table1

The Decay setting (Table 2) concerns the descent front of the pulses for driving the motors, and it may be more or less steep, depending on the expected behaviour; by means of the DIPs 3 and 4 it is possible to set the following modes: FAST, 25%, 50%, Slow. The Slow setting corresponds to a slow voltage decay, while  “FAST” corresponds to a quick decay (normal functioning). With steep fronts the motor has no inertia, but if there are recurring stops and restarts, the said setting must be abandoned, in favor of a slow decay (Slow or 50%).

Table2

The relay for the electro-spindle’s powering is commanded in the on/off mode by the specific output of the board, at the command given by the machine’s control software (e.g.: Mach3). Still on the subject of the electro-spindle, please notice that its power is not a regulated one, therefore it is normal that – when under load (that is to say, when the milling machine is in contact with the workpiece and the motor is under strain) – it may even go at a bit more than 40 volt.

Using it along with Mach 3

For a correct usage of the 3-axes controller board along with the Mach3 software, it is needed to change the settings, as indicated as follows.

• Please open Mach3 and select “Port and Pins” from the Config menu.
• Select Port#1; the address of the parallel port 1 must be 0x378.
• Set 25000Hz in the Kernel Speed box. With more performing systems, please select a higher value (this influences the motors’ maximum rotation speed).

Please move on to the “Motor Outputs” board.

• Enable the command signal as regards the X, Y and Z axes (Enabled) by clicking in the corresponding box. The green tick will indicate the “active” condition.
• Enter the pin number corresponding to the parallel port in the “Step Pin#” box, for each axis  (X=2; Y=4; Z=6).
• Enter the pin number corresponding to the parallel port in the “Dir Pin#” box, for each axis (X=3; Y=5; Z=7).
• Enter the number “1” in the “Step Port” and Dir Port” box, for each axis.

Please move on to the “Input Signals” board and:

• enable the X++, X–, X Home, Y++ limits, etc… as a function of the microswitches that have been actually installed on your machine, and that have been connected to the board’s (5-poles) LIMIT connector;
• set “1” in the corresponding “Port#” boxes, by entering the corresponding PIN number; it may be detected from the parallel port LPT1’s table of pins, that can be found at the box, two pages before this one;
• please tick “Active Low” only if the switch of the corresponding limit closes towards ground (GND) when activated;
• if you are using the emergency button, please tick the EStop entry, and set “1” in the “Port#” box and specify the Pin Number “17”; even in this case please tick “Active Low” only if the switch of the emergency button closes towards ground (GND) when activated.

Please move on to the “Output Signals” board, here you will have to operate as follows.

• Please enable Digit Trig, Enable1, Enable2, Enable3 and Output#1 by clicking in the corresponding boxes. The green tick will indicate the “active” condition.
• set “1” in the corresponding “Port#” boxes.
• Specify the Pin Number that has been assigned to each entry (16 for Digit Trig, 16 for Enable1, 16 for Enable2, 16 for Enable3 and 17 for Output#1).
• Once all the configurations have been completed, please click on the OK button.

Configuration of the  parameters of the motors

Let’s move on to the configuration of the parameters for the functioning of the motors; the procedure is as follows.

• Please select “Motor Tuning” from the Config menu.
• Please click on the “X Axis” button on the right, and then set the following parameters:

– “Steps per” (the value for the steps per mm; it depends on the microstep settings chosen and on the type of motor/screw coupling that is used by the machine);

– Velocity In’s or mm’s per min.” (it sets the motor’s rotation speed);

– Acceleration In’s or mm’s/sec/sec” (it sets the motor’s acceleration);

– Step Pulse and Dir Pulse (it sets the duration of the pulse, in microseconds).

Once you the selection of the settings has been completed, please click on the “SAVE AXIS SETTINGS” button.

Please repeat the same procedure for the other axes and then exit the configuration, by clicking on the OK button.

Choosing the voltage power

A special discussion concerns the power voltage of the stepper motors, since generally the greater the voltage, the greater is the engine’s torque at a high speed functioning; with a consequent reduction in the risk of step losses (that may particularly occur in the microstep mode); however, this may damage the driver and implicates an increase in the motor’s vibrations at low revs. The board uses the same power voltage of the motors, therefore there should not be any problem. Please do not modify the said voltage, since it is the one that turned out to be the best one.

Usage notes

Once the machine has been completed, in order to use it please restart the computer and the software, then give voltage to the machine; it will remain inactive until the command is given from the software.

As for the usage, please remember – as a first thing – to keep the boards far and protected, and the same goes for the power supply and the transformer, that we advise to screw to a wood base or to the bottom of a box (if you wish to use it) by means of 3MA screws with nuts. Please also and above all protect the switching power supply, given that its container is a grid, whose holes may let some dangerous elements (such as metal shavings and scraps, coolant) in.

Please remember that the electro-spindle supports all kind of rotating tools whose beam has a diameter of up to 1/8 of an inch, that is to say, 3.17 mm (the collet chuck widens up to that diameter).

Conclusions

In this article we presented a new CNC machine: it’s a very performing one, and one having an excellent value for money; the machine’s control electronics is suitable for the interfacing on a parallel port: however, if you do not possess such a port and if you only have the USB one on your computer, do not miss the next installment! In fact, we will then publish a supplementary board, to be connected between the 3-axes board and the computer. Its peculiarity is that it receives the commands for the three axes from the control software and that it locally generates the pulses that will then be sent to the parallel port.

From openstore

CNC mechanics – kit 200x180x60

Spindle motor 36 Vdc – 300 watt

set board 3 axes + accessories

Switching power supply Mean Well 24 Vdc 150 W

Bipolar stepper motor NEMA 17 – 1,5 A

RandA has been updated to be compatible with the 3rd version of Raspberry Pi: let’s going deep and explain all the new features.

As you probably know, if you are familiar with the evolution of the raspberry board, in February of this year the 3rd new version of Raspberry Pi has been launched on the market. It is a hardware update of the reference model Raspberry Pi 2 that brought major improvements and a development of hardware performances, in regards to:

• CPU, which is now a quad-core 64 bit ARMv8 clocked at 1.2 GHz;
• A Wi-Fi transceiver (801.11n) has been added, to support the already present wired Ethernet LAN;
• A Bluetooth 4.1 transceiver has been added.

Luckily, the mechanic layout of the board and the 40-pin expansion bus have not been modified, so nothing changes in terms of connections for the interface with RandA, our board which complements the Raspberry Pi’s potentials with the boundless world of Arduino.

For those of you who still don’t know RandA (contraction of Raspberry and Arduino), let’s say it overlays to the Raspberry Pi board keeping the same size factor and encumbrance of Raspberry Pi (from model Raspberry Pi B+ onward). It is connected to Raspberry Pi through a 40-pin connector although just a few are used, to wit:

– GPIO2 and GPIO3 (3-pin and 5-pin) for connecting to the clock through the I²C-Bus;

– GPIO14 and GPIO15 (8-pin and 10-pin) for interfacing with Arduino through the serial TTL;

– GPIO22 (15-pin) for an additional connection to Arduino (it can be omitted);

– GPIO23 (16-pin) to control Arduino’s reset;

– GPIO24 (18-pin) to detect the status of the off button;

– Power pin, i.e. 5V, 3V, GND.

RandA contains the hardware of an Arduino Uno that is put into communication with Raspberry Pi (inserted through the above-mentioned 40 pin connector) via its serial port and has a series of standard connectors and connectors with Arduino layout to host possible shields.

It also contains an RTC module (clock) with backup battery and programmable alarm clock (switching on), a button-operated on/off the circuit (shutdown) and circuitry to control power for Arduino and Raspberry Pi.

RandA is an interesting board in and of itself thanks to its feature that allows interfacing the versatility and diffusion of Arduino with the potentials of the Linux operating system running on Raspberry Pi, but now, with the remarkable calculation power and the general performance level achieved by Raspberry Pi 3, it becomes even more interesting and stimulating for application developers whether at amateur, semi-professional and professional level.

In fact, let’s not forget that Raspberry Pi is essentially a computer with Linux operating system and complete with all the standard interfaces that allow it to go on the Internet. Besides, the calculating heart is, in the latest version, a 1.2 GHz quad-core CPU with 1 GB RAM.

Its mass memory is based on microSD cards, which as of today can have considerable speed and storage space, especially if we take into account their affordable prices.

RandA adds to this the possibility to implement, for instance, a practical and truly fully configurable interface for sensors and actuators. If you want to know more about RandA, we remind you that the board has been introduced in this post.

RandA, Raspberry Pi 3 and Raspbian Jessie

However, RandA is more than just a hardware expansion. In order to explicate its potentials, RandA needs an interface software with the Linux operating system running on Raspberry Pi. Special attention must be dedicated to the serial port management; unfortunately, Raspberry Pi 3 uses the standard UART0 serial port (so-called from the operating system ttyAMA0” or “serial0”) for connection via the Bluetooth interface equipping version 3. Therefore it is no longer available on GPIO14/15 (8/10-pins) as it was the case for the first and second version of Raspberry Pi. In fact, the secondary UART1 serial is configured on those pins. The problem is that this serial port (called “ttyS0” or “serial1” by the operating system) is not based on a preset UART hardware but on a simulated serial. In particular, its clock is connected to the frequency of the clock of the system which, as it is the case in a modern system like the Raspberry Pi, varies in function of the load in order to save energy.

We’d better not use this reduced and less-efficient software version of the serial port for an important connection like the Arduino connection. Therefore, our only option is to recover the UART0 on GPIO 14/15 pins. Luckily, it’s just a matter of software configuration, therefore we don’t have to modify the RandA layout.

However, this way we deactivate the Bluetooth peripheral. On the other hand, we must remember that Raspberry Pi 3 is equipped with Wi-Fi by default, therefore wireless connections are guaranteed by it. If you really feel the need for a Bluetooth connection, you can always buy a USB/Bluetooth dongle at a very low price.

In any case, the Bluetooth is now connected with the UART1 (ttyS0 or serial1), so it’s probably better to deactivate it, especially if you are going to install a USB/Bluetooth dongle.

Latest versions of Linux kernel and Raspberry Pi firmware are based on “device trees (dt)” management to configure hardware on Linux. In particular, we can launch preset routines in “/boot/config.txt” in order to modify configuration and management of the onboard hardware components. To be more specific, reconfiguration of UART0-UART1 can be obtained by giving the following command (still in “/boot/config.txt”):

dtoverlay=pi3-miniuart-bt

This way we bring UART0 back on GPIO14/15 while UART1 is connected to bt (Bluetooth).

Complete deactivation of Bluetooth can be obtained with the command:

dtoverlay=pi3-disable-bt

Actually, activation of I²C-Bus referral which is necessary to connect to the clock can be made in “/boot/config.txt” with the command:

dtparam=i2c_arm=on

All the preset routines are contained in directory “/boot/overlays”.

Meanwhile, the website dedicated to the customization of the Linux-Debian operating system on the Raspberry Pi hardware made a new major version of the operating system available, called “Jessie”. In this version of Linux-Debian, the official launch system becomes “systemd”, instead of the classic “sysvinit”. The activation/deactivation of services is now made via the “systemctl” command, through an informative structure allocated in the “/lib/systemd” directory. This is why we had to modify the activation of the “power off” executed at shutdown. While we first had the script “ups-monitor”, now the “PowerOff”  program (which deactivates power through the clock circuit) is launched by the “RandApoweroff.service” script, conveniently inserted in the informative structure of “systemd”.

We didn’t have to furtherly modify the management software of RandA, however, with the Raspberry Pi update we took the chance to make a general revision of the firmware in order to check and enhance its functioning.

In particular, the software for remotely programming Arduino can now be downloaded only in its full version, in fact, the Arduino IDE V1.0.5 editing kit is no longer provided. It’s called IDE4RandA and it also includes a separated command “SearchRanda.jar” which simply lists the addresses of all the RandAs found in a local network.

IDE4RandA has also be verified on Windows 10. It also includes an important information page about how to activate Windows firewall in case it blocks communication. Informations are available in Italian and English.

Repository folders of compiled sketch storage

Both remote and local IDE, for the Linux environment, save the compiled sketches (executables) in the folder “/home/ArduinoUpload”. Another folder called “/home/ArduinoHex” is dedicated to executable sketches moved by the user in such position. From these two folders, we can select the sketches to be loaded on Arduino through the command (“ArduLoad”) or the web interface.

WEB Server

It is still based on the Tomcat software and it’s been revised for what concerns its interface pages with the serial port. Since Java does not include libraries to manage the serial line “RXTXcom.jar”, we can see a misalignment between Java, the library copied by the installation process or another version installed by other packages like Arduino IDE for Linux.

This is why they decided to turn the Java “servlet” used by these pages in a CGI script (or better, two scripts). Two things have been achieved this way, we don’t have any problems managing the serial and they have provided an additional example of how we can manage a sophisticated HTML page with AJAX, by interacting with a simple script bash that takes care of interface and Arduino.

In fact, while Tomcat is essentially an application server preconfigured for Java “servlet”, it’s been configured to also execute script bashes (or Python) with the advantage of an increased readability and debugging ABILITY.

Example sketches

They have reorganized and divided into the two following types.

• Examples related to the use of library “RAComm” for Arduino which allows the sketches to launch commands on Raspberry Pi. These have not been modified. They have been inserted as library examples, both in the remote IDE and in the local one; among them, we can find those that allow Arduino to send an email or make it read a webpage.
• General examples. These have been placed in the other standard examples in the remote IDE, while on the Raspberry Pi they have been placed in the “sketchbook” folder. They are:

– SerialIO = it allows to completely manage Arduino’s pins by commands sent on the serial line and it is used by the web interface via the page “RaspDuinoIO.html” or the command (script) ArduIO, but it can actually be used by any console or serial connection;

– SerialTest = it allows to run a simple check of the serial connection through blinking of the standard LED with adjustable time of the value sent;

– SerialStop = it does not execute a replay on the serial until a certain condition is met on a digital or analogic pin; it is used by the command “ArduInt”;

– SerialServos = it manages the servos through serial commands.

All the examples implement the itsMe() functions which return the sketch filename after the “?” The command is sent. This function is useful in order to determine on the fly which sketch is active on Arduino.

void itsMe()
{
char name[]=__FILE__;
char* c=strchr(name,’.’);
if (c != NULL) *c=’\0’;
Serial.println(name);
}

Documentation

There is a short English manual in the installation software, now updated to the new version. In around 20 pages the manual provides an overall description of connections, settings, hardware and software.

However, a bona fide Italian manual of around 100 pages should soon be released, where, besides a more in-depth illustration of hardware and software, a step-by-step approach to use RandA is provided in its multiple operational points of view with several examples.

Downloading the software (version 1.5)

The most recent software version 4 RandA is the 1.5, which is compatible with Raspberry Pi 3 and is based on the Linux-Raspbian-jessie version of the operating system. You can download the software here.

On this website you can find:

• a “.txt” file with release notes (both in Italian and English);
• the English booklet (pdf);
• the PC software contained in the IDE4RandA.zip file, which must be copied and unzipped on a Windows PC; it contains the Arduino IDE with remote control of RandA over LAN;
• the RandA-V1.5.zip file, which contains the software installation archive and the script that manages it and installs it on a Raspberry Pi board equipped with an operating system Raspbian-jessie;
• the image file of the SD memory card, complete with operating system and RandA software, to be inserted in Raspberry Pi in order to make it immediately operational; the image “RandA-V1.5-Debian.zip” (after unzipping) must be copied on a blank SD memory card with at least 8 GB memory using the famous PC utility Win32DiskImager (which can be downloaded here.

Beside the supplied software contained in the standard Raspbian installation, the system also contains the local Arduino IDE, the IDE for C++ Codeblocks and the very useful “xrdp” server which manages the “Remote Desktop” Windows protocol, in order to allow the full-screen connection between Raspberry Pi and its whole graphic interface through a local network. Very well, we think this wraps up everything you need to know in order to develop your projects using Raspberry Pi 3.

From the store

Raspberry Pi 3

Randa

Let’s print the PCBs by means of our CNC machine, that this time has been fitted with a controller that connects to a PC via USB, that draws the control signals and that regenerates timed pulses, simulating the parallel port.

In this post you had the chance to learn about and to evaluate our new CNC milling machine, equipped with a 9,000 rpm electro-spindle and with a compact PVC chassis, and available in assembly kit. This machine, that stands out for the excellent value for money (which is suitable for an amateur CNC machine) has been thought mainly for engraving plaques (such as those for the mailbox, the intercom, the door) and plastic elements (even in POMs, Delrin included). It is then surely possible to work with wood and, without overdoing it, it is possible to engrave (but at a low depth) aluminium plates. In this article we will show you how to use it, for the purpose of engraving printed circuit boards by means of an open source software and a refined hardware solution that enables the management via USB, from the PCs that do not have a parallel port.

As with most CNC machines, even ours is supplied with a 3-axes control board that is interfaced to the parallel board, so that it is possible to drive it by means of software of the Mach 3 kind, that converts the G-code into pulses that are directly produced on the parallel port. Since many desktop PCs and all the notebooks no longer have a parallel port, we thought to a solution that will be described in these pages, and that enables to directly drive it via USB, and therefore by means of all the modern computers. We created this specific board since – in order to manage the CNC machine via USB – it is not sufficient to use a traditional USB/parallel adapter; in fact, as the data would be sent on a virtual LPT and in serial form (since the USB is a serial) and then recomposed in parallel form with a certain delay or, worse, with unequal delays among the bits: this would bring to a situation with movements on the three axes that are not perfectly synchronized, and therefore to mistakes when manufacturing the workpiece.

On the other hand, our proposal is that of a hardware that – by starting from the USB and by taking advantage of the open source software – enables to reconstruct the command pulses for the CNC control board on the machine. It, therefore, enables to keep the original electronics and adds a device that is something more than a simple interface.

The system

In order to understand the usefulness of the interface, it must be said that – in common CNC machines that work on LPT port – the command is usually given by the manufacturing software (e.g.: Mach 3) that starts from the file in the G-code language and extracts the pulses and sends them directly on the lines of the parallel, so to make the corresponding axes advance for a certain number of steps/mm. In practice, Mach 3 executes the G-code and emits specific pulses for the motors, one for each parallel’s pin, and they are synchronized and temporally coherent among them.

If we tried to communicate via USB by means of an adapter, there could be – because of the latency – some synchronization problems among the pulses (since Mach 3 commands the motors via the parallel’s pins and the lines via drivers) and temporal coherence. It is therefore not recommended to use a USB/parallel adapter.

We worked around the problem and created something that is actually a converter subsystem of the commands sent by the CNC control software: a board that connects to the USB on a side while – on the other one – it connects to the 3-axes controller board’s parallel of the CNC machine, via a DB-25 connector. The board converts the received commands, it extracts them from the serial strings arriving on the USB and reconstructs the commands on a parallel connection, by reassigning them the right timings and the temporal coherence, by means of the pulses of all the command lines.

The reconstruction of the command pulses on the parallel – starting from the commands received on the USB – is carried out by an ATmega2560 microcontroller interfacing an USB/TTL converter. We loaded the grbl firmware on the microcontroller: thanks to that, our board receives the G-Code coordinates via USB, and locally generates the pulses on its own parallel, that drives the printer’s original controller. Because of the way the chosen firmware operates, we may not use Mach 3, but only a program that works on USB, such as grblControl, that sends data concerning the coordinates in the format read by our board.

Circuit diagram

Let’s take a look at the board’s circuit diagram, that revolves around the U1 microcontroller, that is to say, the same ATmega 2560 found in the Arduino Mega and Fishino Mega boards; at the start (after the power-on-reset), the microcontroller initializes the PE0 and PE1 lines (respectively as input and output for the data that has been exchanged on the USB, by means of the U3 converter), while PL0, PB6, PB5, PB4, PH4, PH5, PA7, PA6, PA5, PA4, PA3, PA2, PE4, PE5, PK0, PB7, PH3 are assigned to the parallel that has been “reconstructed”, with which to communicate with the CNC controller board. Given that it is a bidirectional parallel, some lines have been initialized as I/Os and other ones as outputs; more precisely, all the lines corresponding to EN, DIR, STEP, RL are outputs (since they send the command pulses to the drivers of the 3-axes board, that is to say, the controller board for our CNC machine), while LIM1, LIM2, LIM3 and LIM4 are outputs, since they are needed in order to read the possible limit switches that it is possible to apply to the machine.

In the following figure helps to understand which ones are the bidirectional I/O lines and which ones are the input lines (printer’s state signals).

On the other hand, the SS, PH0, PH1, PA1, PL3, PL4, PL5, PC0, PC2, PC4, PC6, PF2÷PF7 and AREF lines are actually free and available for possible future developments and evolutions concerning the firmware; we reported them on the CN1 and CN2 connectors for the purpose.

The PK1 line has been assigned to the FEEDH, while the PK2 has been assigned to the CY-ST: both have been initialized by the firmware as inputs, with the pull-up resistor assigned, and they are needed in order to manage the suspension of the cycle. In practice, it is needed to connect to it some normally open buttons that are connected to ground. By pressing the one that is connected to FEEDH the manufacturing is paused, in the sense that only the command series left in the microcontroller’s buffer is executed: after that, the system is paused, the stepper-motors are halted and it waits for a restart command. The bogie and the tool holder head are left in the position in which they were when executing the last command left in the buffer.

In order to restart the cycle, you will have to press the button connected to CY-ST, that works as a “restart” command: the machine’s control software – if fitted for the purpose of recognizing it – will receive and execute it, and so it will restart the data sending on the virtual parallel that is assigned to the USB.

On the other hand, ESTOP is initialized as an input (still with the internal pull-up resistor assigned), and it must be connected to a possible red STOP emergency button. In this case, when it is pressed, the relay output is disabled and the PWM SPIN one as well (for the purpose of stopping the electro-spindle), and our board communicates the stop to the program that is used for managing the CNC machine. The latter requires a manual restart of the manufacturing, that may be restarted from the beginning or from the point in which it was forcibly stopped (in the latter case, please make sure that the restart position is the correct one, otherwise the workpiece will come out poorly).

The ATmega’s PH6 line is initialized by the firmware as an output, with an internal PWM module assigned, and it is used in the case we wanted to directly control the rotation speed of the electro-spindle’s shaft: in fact, it emits pulses that control (they are conveniently buffered by the NOT U2 logic port and amplified in current by the NPN T3 transistor, that is mounted as a common emitter and used as a static switch) the T4 power MOSFET’s gate, at whose drain the PWM SPIN output for the electro-spindle commanding refers to (the electro-spindle should, therefore, be connected between the PWM SPIN output and the power supply’s output positive). In that case, it is needed to join the ground of the electro-spindle’s power supply with the board’s one, as close as possible to the MOSFET’s source, given that the latter operates as a static switch and that it commutes the PWM current pulses on the motor.

The output for the signal of the direction control has been assigned to the PE3 line. It is useful in the case you wanted to drive the electro-spindle’s motor by means of a MOSFET bridge, that enables the inversion of the current flow.

If you prefer the traditional control (the on/off one implemented by the actual 3-axes CNC controller board), the PH3 line drives the NPN T2 transistor, whose collector powers the usual relay with which the 48Vcc power supply’s line on the electro-spindle is commutated.

Please notice that in this project the control of the electro-spindle’s power relay does not occur by means of the output placed on the CNC’s 3-axes controller board, but it is “carried out” onboard, so that it is possible to implement even the proportional control via PWM.

As for the limit switches, we have to start with a small digression: the basic CNC does not have any limit switches, therefore the zeroing of the positions on the three axes (X, Y, Z) must be manually carried out, by ordering the control program to execute a given number of steps, until the position we consider to be the zero is reached. For each production, the machine starts from the current position of the tool holder head and the plate, since it gives the movement coordinates concerning it.

If you’d like to have some references, such as the one for the Home position, you will have to mount (in addition to the existing hardware) some lever microswitches, so that they may detect the said position, for each axis. The said microswitches must be fixed so that their lever is pressed when the corresponding sliding part in the mechanism is in such a position so to correspond to the home position. Please notice that on the grblControl’s user interface (that’s the software we will be using when managing the CNC machine) we have both the Machine coordinates and the Work coordinates: the first ones are those of the machine and they may be obtained via the limit switches or by zeroing the machine, after having manually brought the electro-spindle to the desired position and after having reset – by means of the dedicated buttons – the position. The second ones are on the other hand those corresponding to the ongoing production.

By means of the limit switches it is possible to define the maximum movement on each axis so that the moving parts do not exceed the maximum travel, and so to prevent pointless collisions.

The microcontroller may be locally reset by means of the P1 button, that acts on the /RST line (that is normally kept at high logical level by the R14 pull-up resistor), or remotely: two possibilities are contemplated, that is to say via USB by means of the specific command given from the computer and by means of the Arduino IDE, during the bootloader activation stage (in this case the USB/TTL converter’s DTR is brought to a low logical level and by means of C5 it supplies a negative reset pulse) or by means of the board’s RESET input, to which a clean contact must be applied, so that it closes the electrodes and sends the T1 transistor into saturation, so that the latter’s collector brings /RST to the logical zero. Please notice the Schottky diode, that is used to turn off the negative pulse that would occur at the ends of the R14, when the U3 converter’s DTR returns to a high logical level.  

Let’s continue with the analysis of the circuit diagram, and see the U3 USB/TTL converter, that is the typical FTDI FT232RL integrated circuit that converts the signals of the USB line in TTL (0/5V) format, and that deals with the due timings; it is an interface of the Device type and supports the USB 2.0 Full Speed communication. On the D+ and D- input lines there is D4, a dual, bidirectional Zener protection diode, that suppresses possible high voltage pulse noises that may be picked up by the USB cable: that is something we should not rule out if we are using the machine in an environment in which other tool machines are operating.  

As for the power source, the board draws from the USB +5V, by virtue of the quite limited absorption of the logic; clearly the USB powers the microcontroller and the LEDs, in addition to a minimum of discrete logic and transistors that are onboard. The USB port’s 5V reaches the power line through the D1 diode, that is used in order to protect the computer’s +5V line, in the case in which the in-circuit serial programming connector (ICSP) is disconnected, without the USB cable being disconnected from the computer. From the diode’s cathode the power – that is well filtered by C4 and C8 – goes through the further filtering of the L1 coil, that cleans it from possible noise pulses (along with C6, C7 and C4, C8, L1 forms a CLC pi filter), and through the microcontroller’s port.

The relay’s coil ( powered by 5V) is powered by the 5V coming from the USB, so to prevent that its commutation disturbs the microcontroller’s functioning.

During the normal functioning, the ATmega2560 microcontroller waits for the arrival of data strings from the USB (on the PE0 pin) and it unpacks them at their arrival, extracts the commands and puts them back together again in parallel form, according to the timings that are required by the 3-axes set board.

The grbl firmware

We explained that the installed firmware is grbl; since it is not compatible with Mach3, as for the CNC control software we had to choose one among the compatible solutions that we will describe in these pages, and in the next installment. Grbl is a firmware that was born for the purpose of parsing the G-code and for its conversion in commands on the three axes of a CNC machine. Therefore the G-code sends the coordinates for the movement on the three axes (for example, in order to trace a square we need 4 coordinates and therefore 4 commands: from a point to the second one, from the second one to the third one, from the third one to the fourth one and from the latter to the first one), according to this typical format:

G0 Xn Yn

In which G’ is the command imposing the movement at the highest speed allowed by the CNC (also known as Quick Movement) and X and Y are the coordinates, with n indicating the position to be reached on each of the specified axes . Similarly, a command defines where to bring the axes’ movement (endpoint) and the speed at which to do it: that’s G1, whose syntax is of the following kind:

G1 X7 Y18 F500

in which the F parameter is the movement speed, also known as Feed Rate, that in our machine corresponds to the number of steps per time unit that are carried out by the stepper motor.

In the case of commands imposing a linear movement, our machine converts the coordinates in the commands into steps to be given to the motor (also, keeping the microsteps in mind), so to carry out the movements required by the commands. Grbl has been created for the Arduino world and therefore it may be installed on boards that are based on Atmel’s ATmega microcontrollers, and that have preloaded the bootloader, by means of the same Arduino IDE. In our case, given that it is an open firmware, we customized it by modifying some parts, and especially those that define the structure of the CNC to which the controller board will be paired. The firmware may be downloaded from github.

The conversion of the G-code instructions

into commands that are directed to the motors for the axes’ activation follows certain rules and is carried out by following a certain logic; moreover, grbl supports some functioning modes and standard managements, such as those of the limit switches, of the emergency stop button, of the electro-tool’s adjustment speed, etc.

In Listing 1 you will see an important part of the firmware (the version we are using is the  GRBL9FMEGA2560), in which the machine’s operational parameters are defined.

Listing1

#ifdef DEFAULTS_FuturaElettronica
// Description: CNC2018 NEMA 17 stepper motors.
// www.futurashop.it/cnc
#define MICROSTEPS 8
#define STEPS_PER_REV 200.0
#define MM_PER_REV 1.25 // 1,25 mm/rev leadscrew
#define DEFAULT_X_STEPS_PER_MM (STEPS_PER_REV*MICROSTEPS/MM_PER_REV)
#define DEFAULT_Y_STEPS_PER_MM (STEPS_PER_REV*MICROSTEPS/MM_PER_REV)
#define DEFAULT_Z_STEPS_PER_MM (STEPS_PER_REV*MICROSTEPS/MM_PER_REV)
#define DEFAULT_X_MAX_RATE 500.0 // mm/min
#define DEFAULT_Y_MAX_RATE 500.0 // mm/min
#define DEFAULT_Z_MAX_RATE 500.0 // mm/min
#define DEFAULT_X_ACCELERATION (100.0*60*60) // 100*60*60 mm/min^2 = 600 mm/sec^2
#define DEFAULT_Y_ACCELERATION (100.0*60*60) // 100*60*60 mm/min^2 = 600 mm/sec^2
#define DEFAULT_Z_ACCELERATION (100.0*60*60) // 100*60*60 mm/min^2 = 600 mm/sec^2
#define DEFAULT_X_MAX_TRAVEL 185.0 // mm
#define DEFAULT_Y_MAX_TRAVEL 200.0 // mm
#define DEFAULT_Z_MAX_TRAVEL 60.0 // mm
#define DEFAULT_STEP_PULSE_MICROSECONDS 10
#define DEFAULT_STEPPING_INVERT_MASK 0
#define DEFAULT_DIRECTION_INVERT_MASK 224 //((1<<Z_DIRECTION_BIT))
#define DEFAULT_STEPPER_IDLE_LOCK_TIME 25 // msec (0-254, 255 keeps steppers enabled)
#define DEFAULT_JUNCTION_DEVIATION 0.02 // mm
#define DEFAULT_ARC_TOLERANCE 0.002 // mm
#define DEFAULT_DECIMAL_PLACES 3
#define DEFAULT_REPORT_INCHES 0 // false
#define DEFAULT_AUTO_START 1 // true
#define DEFAULT_INVERT_ST_ENABLE 1 // true
#define DEFAULT_INVERT_LIMIT_PINS 0 // false
#define DEFAULT_SOFT_LIMIT_ENABLE 0 // false
#define DEFAULT_HARD_LIMIT_ENABLE 0 // false
#define DEFAULT_HOMING_ENABLE 0 // false
#define DEFAULT_HOMING_DIR_MASK 0 // move positive dir
#define DEFAULT_HOMING_FEED_RATE 25.0 // mm/min
#define DEFAULT_HOMING_SEEK_RATE 250.0 // mm/min
#define DEFAULT_HOMING_DEBOUNCE_DELAY 250 // msec (0-65k)
#define DEFAULT_HOMING_PULLOFF 1.0 // mm
#endif

Among the parameters, we may notice MICROSTEPS, that indicates a possible reduction to the microstep mode (that must be exactly like that in the 3-axes controller board), STEPS PER REV (steps/rev for the motor at the corresponding axis), MM per REV, that is the distance on the axis per each revolution (1.25 is due to the fact that we are using M8 threaded rods, having a 1.25 mm pitch). The settings for the axes follow; in particular, please notice that the STEPS PER MM are the steps required for a 1 mm movement, that are obtained by means of the following calculation: step/rev x microstep/mm x mm/rev. MAX RATE is the linear speed, that depends on the frequency of the pulses driving the stepper motors, and it may be set between 500 and 6000 (we chose 500); that’s the maximum idle speed. The maximum speed when manufacturing on the other hand depends on the resisting force met by the electro-tool.

The section that enables to communicate the axes’ travel and the presence of possible limit switches to the machine is an interesting one: DEFAULT_X_MAX_TRAVEL indicates the  travel on the X axis (185 mm), DEFAULT_Y_MAX_TRAVEL indicates the travel on the Y axis (200 mm) and DEFAULT_Z_MAX_TRAVEL (60 mm) indicates the travel on the Z-axis (electrospindle). SOFT_LIMIT_ENABLE concerns the enabling of the firmware limits (at 0 they are disabled) while HARD_LIMIT_ENABLE enables the reading of the limit switches (it must have 1 as a value). HOMING_ENABLE enables (when set to 1) the automatic return to the HOME position.

Therefore, after having downloaded the software in the GRBL9FMEGA2560 version, you will have to edit it by means of the Arduino IDE and set the parameters as in the section shown in the Listing 1 , otherwise the machine will operate in an improper way (for example, the movement might exceed the acceptable one, with the risk to damage the mechanism).

As for the connections, please follow the figure, and remember that the power source of the electro-spindle’s power transformer has to enter through the V_SPIN clamps and exit through SPIN, and to respect the indicated polarity (therefore the external relay of the 3-axes controller board is no longer needed).  Af for the usage, you will have to connect the USB / parallel board’s USB socket (by means of a USB A/B cable), and the board’s DB-25 connector to the CNC 3-axes controller (by means of a male/female cable, having two DB-25 at the ends). If the electro-spindle’s power is commutated by the board’s relay, you will have to connect the power rectifier bridge’s positive and negative poles to the corresponding poles of the V_SPIN junction box, and the electrospindle’s wires to the SPIN’s + and -; please notice that, since they are clean contacts, it is actually possible to swap the places of the terminal boxes, that is to say that V_SPIN may be used in order to connect the motor and SPIN may be used in order to receive the 48Vcc power.

As regards the power source, please remember that the board described in this article does not require any power supply in order to operate: in fact, it draws the 5 volts needed from the computer, by means of the USB socket it is connected to. The electro-spindle’s power is simply commutated, but it does not reach the electronic parts.

The adapter board must be inserted in a dedicated plastic container. As for the latter, it is needed to create a window for the USB connector, another one for the DB-25 and another one for the passage of the wires for the electro-spindle and for the possible limit switches that you might have added to the basic CNC machine. It will be possible to fix the emergency stop button (to be connected to the dedicated input contacts) on the container, or close to the CNC (maybe in a box for external electrical systems, a watertight one).

The same goes for the reset button, that you will put on a side of the container, and for the possible pause button (FEEDH) and for the restart one (CY-ST).

Conclusions

Well, we are done, at least as regards the hardware. In the next installment we will show you how to use the interface/CNC whole, for the purpose of crafting printed circuit boards, and without printing anything, without photoengraving, felt pens, films, PCB development, and acid solutions. Here they are literally engraved, by means of a specific tool mounted in the electro-spindle.

As usual, we will start from a gerber file (that is the standard, nowadays, as for the industrial manufacturing of PCBs). The first thing to do is to acquire a CAM, a computer assisted design software, for the creation of elements and mechanical systems. In our case, we will explain how to work by means of FlatCam, that may be downloaded from Internet, at the following webpage: http://flatcam.org/. Once it has been downloaded and installed, please start the FlatCAM program. As for the CNC control software, let’s choose one among the ones that are compatible with our hardware and with the grbl firmware: there are many open source ones; among those offered by the market, we chose grblControl, whose usage will be described in depth in the next installment.

As for now, we will limit ourselves to analyze its main aspects, that is to say the installation and the elements that may be found in the work screen; in the next article, in which we will see how to use if for the printing, everything will be clearer.

The software is free to use and may be downloaded at the https://github.com/Denvi/Candle webpage, in the form of a compressed folder; by unpacking it, the grblControl folder will be obtained: inside of it, we will find the grblcontrol.exe executable file. By clicking on the corresponding icon, it is possible to start the program, whose work screen is the one shown in the figure.

In the central box you will find the workpiece’s design, while in the upper part of the screen there is the menu bar, including the File, Service and Help menus: for example, the first one enables to open and save the file on which you are working on, while the settings are found in the second one.

On the right, you will find the control panel, with the State section found in the upper part, the Control one found in the lower part,  and so on. State indicates the CNC machine’s condition (idle or working) while the Work coordinates and Machine coordinates indicate the coordinates at which the three axes are located: in the first case the ones concerning the work being executed are displayed, while the ones concerning the machine are displayed in the second case.

In the Control box, the commands for the manufacturing and the buttons (the two ones on the right) for zeroing the coordinates are gathered. There is also the Spindle box, in which it is possible – if the PWM speed control is activated on the board  – to modify the electro-spindle’s revs/min. The console box shows the commands being executed and enables the possibility to give them in G-code.

From openstore

CNC controller USB card

CNC mechanics – kit 200x180x60

Spindle motor 36 Vdc – 300 watt

set board 3 axes + accessories

Switching power supply Mean Well 24 Vdc 150 W

Bipolar stepper motor NEMA 17 – 1,5 A

Let’s build an interactive table equipped with a display and manual commands to create everything from videogames to animations for communication, teaching and entertainment.

LED strips with serial control, and Neopixels in particular, allow us to create, when conveniently combined, many lighting effects and even matrix displays that can go up to remarkable dimensions; this is the consideration that sparked the idea for this project, which is basically a videogame table with a huge LED matrix Neopixel display, made of many strips connected in parallel. The initial idea was to create a table capable of implementing a series of lighting effects and at the same time could also be programmed for other uses, e.g. videogames, panel for visualizing moving texts, display for instructional animations etc. We have been built upon that idea because, since the display unit we have created can compose anything, from text to images, a few more lines of code allowed us to build both controls and animation for a videogame, specifically the renowned arcade game Tetris in a tabletop version with a giant screen. In order to create our prototype we’ve started from a base table, a LACK table from IKEA to be more specific (you can find it on www.IKEA.com) that we have picked for its practicality, low cost and high availability (the “DIY furniture” giant has now created a comprehensive network all over Italy and it also sells products online) and because we can easily work with it (the table is made of MDF honeycomb panels, so we can easily “dig” into it and pass the cables).

On the top panel of the IKEA table we applied some RGB LED strips taken from 5 m Neopixel strips, each with 300 LEDs (code STRIP300LED); to be exact, the display is composed of 1260 individually-addressed RGB LEDs.

On the table, we have placed the controlling electronics, which is composed of an Arduino Mega board that interfaces with the player through an arcade joystick (code JOYSTICKASH) and an arcade videogame button (code COM09340).

The joystick has been installed onto the table by hollowing out a cavity and attaching it with some screws, while we have screwed on the button, again after hollowing out an appropriately-sized cavity, with a bigger diameter in the lower part in order to tighten the button with its nut and washer.

Everything is powered by a stabilized AC/DC switching adapter that outputs a 5 V voltage (code RS-150-5).

Electronics

So, let’s take a look at the electronics part of the project, which is basically a display unit and control hardware; the first is, as we already mentioned, a matrix divided into rows, each one composes by a LED strip segment. Using a Neopixel RGB LED strip allows us to address each single LED and choose the color individually, among all the possible tones, and a range of 256 combinations for each base color (therefore we have 256×256×256 combinations!) for a total of 16,777,216 colors. That’s not forgetting that Neopixel, for each RGB LED portion of the strip, integrates a driver and the corresponding RGB LED in SMD and therefore the direct LED control for each one. Data channel for communication is a 5 V-powered oneWire serial channel; Neopixel LEDs are connected in cascade so that the input data line, besides reaching the corresponding controller, is repeated on the output. Communication on the data channel takes place at a maximum rate of 800 Kbps and has an embedded clock. As it is the case for the individual LEDs, we can connect more Neopixel strips in cascade to create various effects. In the strip, the serial control is crucial because otherwise we would need too many lines in order to control the single LEDs composing it, even if we employ a multiplex matrix control system.

As we just mentioned, LEDs of the Neopixel system can be connected in cascade so that the data line of the previous one goes to the next one, but the price to pay is that beyond a certain number of LEDs, control speed must be sensibly reduced; because of this, if you need to create matrixes to display fast-moving graphics it is a better idea to employee multiple lines with a few LEDs each; however this is not our case, because the animation is relatively slow in Tetris.

In short, refresh frequency and therefore the on/off speed of each single LED is inversely proportional to the quantities of LEDs we have to manage.

For each LED strip we can decide what refresh frequency we want to set, in order to make certain lighting effects barely noticeable. In our case, LED scanning frequency is 400 Hz. Maximum data transfer speed influences, controllable LEDs number being equal, the image’s refresh frequency, because all control data travels on a single serial channel; this means that the more LEDs we have to manage, the lower the refresh frequency and therefore the lower the movement speed of the displayed image.

How it works

The control protocol of the Neopixel system calls for the cyclic sending (at a frequency dependent on the frequency of the refresh we want for the display unit) of data strings each one composed of 24 bits divided into three byte groups (therefore 3×8 bits); each byte of a 24 bit string contains the illumination status of each base color in this order: first the eight green bits, then the red ones and finally the blues ones.

Inside each Neopixel strip, every single smart LED is connected in cascade, since data line going into the DI terminal goes out of the DO, which repeats all the data. Reference mass for power and data (it is a single one and connected to the G contact of the strip) is mobile, so it goes in from one end and comes out of the other.

In terms of wiring scheme, we can see that Arduino Mega controls all the strips composing the display unit, using just one data line, so the DI contact of the first segment connects to the I/O of the board and the DO connects to the DI of the following segment, and that DO connects to the DI of the following strip. The connection is repeated until the last segment, which DO contact stays open (no terminal is needed here).

Data line corresponds, in Arduino Mega, to digital 2-pin, set as output.

Strip powering takes place in cascade, but since it is in parallel between start and end, it is actually in parallel, with the exception of the resistance of the strips; for obvious absorbance reasons it cannot be provided by Arduino but it has to come from an external adapter, connected as we are going to explain when we will talk about the construction of the table display unit. Power ground is common with data ground, therefore the GMD contact of Arduino is connected to the GMD of the first strip.

That’s getting back to the Arduino now and we can see that, besides the strips, we have also connected a button and the joystick; the button is normally open and connected to the 7-pin of Arduino and to ground (the pull-up resistance is software-enabled on the corresponding Atmega pin, this way we can do away with an external resistor and simplify the wiring).

The joystick is the classic arcade style joystick, so each one of the four movements corresponds to one button closing; its lever position is therefore detected by means of four digital lines on Arduino Mega, each one configured as an input with an internal firmware-enabled pull-up, which are:

• digital 3-pin 3 for lever up (block rotation);
• digital 4-pin for lever right (right movement of the Tetris block);
• digital 5-pin for lever left (left movement of the Tetris block);
• digital 6-pin for lever down (fast descent of the Tetris block).

Once power is provided, Arduino loads this sketch and periodically checks the button status; at the same time it starts the preset lighting effect. When the button is pushed for the first time the game is launched and Arduino tracks the status of the joystick and the button, in order to move the displayed elements based on the received commands. Synchronization between displaying and commands given by the player through the joystick potentiometers can take place because Arduino Mega checks, with each movement imposed to the object on display, whether the button is pushed or the joystick lever is moving; based on when the command is received, it acts accordingly (for instance, if one block have been already put down and no new block has appeared on screen, it ignores the joystick movement).

Strips management

Images composition on our display is created by indexing one by one, in rapid sequence and line by line, all the 1260 LEDs and by sending to each one of them the data corresponding to the status of each of the RGB diodes composing them, which is expressed through a 0-255 value, where 0 means turned off and 255 means turned on and fully bright. This pattern is scanned multiple times per second in order to trick the eye into seeing a full square each moment, instead of its dot-by-dot composition.

This work required coding a sketch that takes up a lot of memory, that is why we have to use an Arduino Mega, which has been chosen because of the flash of its microcontroller and the size of the programming memory, and not for its number of I/Os, since, as you have just seen, we need so few of them for controlling the system that we might as well use an Arduino Uno.

In order to simplify coding we make use of a dedicated Arduino library which implements the control of Neopixel strips; it is an open source library that can be downloaded from http://fastled.io/ along with a great variety of examples on how to use it.

In fact, we have modified these examples in order to create our table display.

The library is very versatile, so it allows us to create many applications, since it gives us the chance to define the overall number of LEDs composing the display unit, how are they connected (S-shape, as it is our case, in parallel, in series on the long side etc.), width and height of the final panel. The way they are connected is used by the firmware to determine their disposition, so that it knows how to send data at the end of a segment of its strip; if we make a display by connecting the strips in an S-shape, therefore all in series with the end of a strip correspondent to the beginning of the next one, based on the indexing order of the Neopixel LEDs, the firmware has to send data all reversed once it arrives at the indexing of the last LED of a strip, that is it has to start over from the last one of the row and move back toward the first one, and then reverse once again after setting the last one. In conclusion, it must send data to the LEDs in a zigzag motion. If on the other hand, strips are connected in parallel, we have to use multiple I/O lines of Arduino and divide the data of the images to be displayed into multiple rows, addressing each one individually but synchronously. What’s more, if we keep the cascade connection but strips are connected with the last LED connected to the first of the strip below it (when we say last we mean the rightmost one with the leftmost one being the first) data sending takes place in a consecutive manner.

At the beginning of the firmware, the I/O’s used as inputs to detect commands coming from the joystick and the button on the table are defined:

#define ROTATE_PIN  3

#define LEFT_PIN    4

#define RIGHT_PIN   5

#define DOWN_PIN    6

#define PULS        7

Right after that, we define output pins for data and variables:

#define LED_PIN        2

#define COLOR_ORDER    GRB

#define CHIPSET        WS2812B

#define MATRIX_WIDTH   30

#define MATRIX_HEIGHT  42

#define MATRIX_TYPE    VERTICAL_ZIGZAG_MATRIX

Specifically, LED-PIN 2 defines data output and LED-PIN 2 is the line to setting send order for data about the intensity of the three colors of the base LEDs (in this case it’s GRB, that is first value of the green LEDs, then the red ones and finally the blue ones) for each string; CHIPSET WS2812B defines the driver type of each LEDs in the strip, which must be specified because the Neopixel technology can be implemented through more than just one chip.

The MATRIX_WIDTH 30 instruction defines a number of rows (LED strips) while MATRIX_HEIGHT 42 specifies the number of LEDs composing each rows of the matrix visualizer: as you can see, there are 30 LEDs horizontally and 42 vertically, since the visualizer will be arranged vertically, that is rotated 90° and then laid on one of the short sides.

If the display were made of just one strip, MATRIX_would have 1 as a number. Finally, MATRIX_TYPE    VERTICAL_ZIGZAG_MATRIX defines the LEDs arrangement and therefore the arrangement of the Neopixel strip segments.

Since we need to set up the library, we cannot load both the firmware’s realizing the proposed applications, e.g. Tetris and the lighting effects panel, despite the memory availability of the ATmega2560; In fact, the two applications require a different configuration of the library. Now, let’s see how the table works in the two provided applications.

Tetris

Once Arduino Mega is launched (that is after powering it on) the firmware will wait for the button to be pressed, because Tetris uses the button in order to start the game; once the game is started, you can control the bricks movements with the joystick: to be specific, when you move the joystick to the left and to right the brick will follow accordingly. Brick rotation can be done by pushing the joystick lever up, while you can speed up the descent by pushing the lever down.

At the end of the game, the player’s score is displayed.

Graphic effects

If we load the graphic effects demo we can, once Arduino Mega is launched, choose which effects to display via the button; moving the joystick lever up or down can increase or decrease the brightness of the LEDs composing the effect, while we can change rotation speed of some of the provided effects by moving the joystick left or right.

Construction

Now, let’s take a look at the construction of the table: we must drill the holes and pass the cables in the IKEA table next to a short side in order to install the button and the joystick. On the remaining part of the table we are going to install the Neopixel strips (that can be found on www.futurashop.it, labeled STRIP300LED) cut in 42 LED portions and arranged along the longer side of the table and side-by-side for a total of 30 strips; this way we are going to create our matrix of 30×42 = 1260 RGB LEDs. The spacing between the strips segments must be adjusted so that the final matrix occupies an overall area of 70 x 49 cm. Data channel for the strips must be installed in series with all of them, therefore the wire coming from the Arduino enter the DI contact of the first strip and comes out of the DI of the last one with a thin (0.22 mm thickness) segment of coated copper wire toward the DI of the adjacent strip and so on. Power and ground must be brought using 0.5 mm thick copper twin leads, because the current absorbed by the system is significant and transportation, if made through wires, would require such a thickness that it would sensibly stick out of the table plane. In order to simplify power connections, the 42 LED segments must be placed with alternated orientation, so that the adjacent ones have the same line near to them, which is alternatively ground and +5 V. So you must start from one side and install the first segment with the GND line close to the edge of the table, then you place the second one next to it oriented in such a way that the 5 V line is next to the 5 V line; in short, it’s just like you had cut and folded the second segment on itself. Then you keep on this way. The photos in these pages will make it clear for you.

We are using a wall adapter with a stabilized 5 V, 130 W (25 A) output, sold by Futura Elettronica (you can find it on www.futurashop.it with code 8220-RS-150-5); we have placed it under the table, attaching it with some self-threading wood screws and we have protected the screw contacts with a 3-D printed plastic cover (also screwed on).

Strip segments must be powered in parallel by placing on the short side of the matrix some 22 x 0.25 mm copper twin leads, providing an effective section of 5.5 mm² that is necessary in order to withstand the strong current absorbed by the 1260 LEDs that can reach over 20 A. In order to limit voltage fall, which is inevitable since the section is not that big and we are working at 5 V, so even just one volt lost would be unacceptable, we have to apply power to multiple intermediate points for each twin lead: three to be exact, equally spaced. Power will be provided by placing the aforementioned holes between the lead and the table, in order to bring as many 2,5 mm² copper wire segments that will be abundantly tin-soldered in the output point. The segments coming from the bottom side of the board are then to be soldered to the wire coming from the power switching used for the system. The twin lead can be placed 4-5 mm away from the strips. Power must be connected by connecting short 0,5 – 1 mm² naked copper wire segments between the twin lead and the pad of the corresponding line, this is how we need to connect every GND pad of the strip terminals next to the ground twin lead and all the 5V’s next to the positive +5 V twin lead. GND and 5 V contacts are then connected to the twin lead alternatively. DIN data contacts must then be connected, side by side, with coated copper wire bridges with 0.5 mm² section.

The Arduino Mega board must be powered with the same 5 V provided to the strips, by deriving a segment of 2×0,5 mm² red – black twin lead from the + and – terminals of the adapter through a terminal and bringing it to the 5 V and GND contacts of Arduino; in order to simplify the connection, we have to solder a pin for each pin strip, e.g. a jumper, to the terminals of the wires on the Arduino side, by insulating the junction with a heat-shrink tube that we can shrink with a blow dryer.

All the wirings on the bottom of the table are enclosed in white PVC electrical conduits, as you can see in the photos. A conduit segment must carry the power wire ending with the wall plug, and which blue and brown wires must be tightened to the terminals, respectively N (neutral) and L (phase) of the switching power adapter, possibly by equipping them with a forked terminal.

The Arduino board must also be attached to the bottom of the table next to the window we have cut for the joystick, so that we can make the local connections with the button and the joystick itself, keeping the wires short and enclosing everything in a square box for electrical systems. Since the IKEA table is made of MDF honeycomb wood (which is composed of two bottom and top panels – spaced out and tied together by a honeycomb structure of pressed cardboard) it is easy to reach the Arduino Mega with the wires passing from the inner side: the power wire and the two button wires. The conduit you see in the picture carries the 5 V power wires of the strips that will then come out of the top of the table.

Once connections are made and the data wire has been brought to the table through a dedicated hole next to the strip pad where it will go in first, and once we apply some 0,5×2 cm wood listels on the edges of the table, attached with glue and let dry, you can put a white see-through Plexiglas board on top of it that is 4 mm thick and 55 x 90 cm in area, that would act as a screen and protect the strips, besides making the overall look of the display more pleasant.

The Plexiglas will also cover the joystick and the buttonholes (therefore you will have to drill a hole in it above the holes you have drilled on the table). Which will be tightened on the table itself with specific bolts.

In order to make the table look even better you can apply PVC or white wood corners, just like those used for picture frames, on the four corners of the table, to cover the Plexiglas-listels block.

Listing

#include “FastLED.h”
FASTLED_USING_NAMESPACE
#if FASTLED_VERSION < 3001000
#error “Requires FastLED 3.1 or later; check github for latest code.”
#endif
#define UP_PIN 3
#define LEFT_PIN 4
#define RIGHT_PIN 5
#define DOWN_PIN 6
#define PULS 7
#define DATA_PIN 2
//#define CLK_PIN 4
#define LED_TYPE WS2811
#define COLOR_ORDER GRB
#define NUM_LEDS 1260
CRGB leds[NUM_LEDS];
int BRIGHTNESS = 255;
int cycle = 200;
#define FRAMES_PER_SECOND 520
void setup() {
delay(3000); // 3 second delay for recovery
pinMode(UP_PIN, INPUT_PULLUP);
pinMode(LEFT_PIN, INPUT_PULLUP);
pinMode(RIGHT_PIN, INPUT_PULLUP);
pinMode(DOWN_PIN, INPUT_PULLUP);
pinMode(PULS, INPUT_PULLUP);
Serial.begin(9600);
Serial.println(“TABLE start - by Boris”);
// tell FastLED about the LED strip configuration
FastLED.addLeds<LED_TYPE,DATA_PIN,COLOR_ORDER>(leds, NUM_LEDS).
setCorrection(TypicalLEDStrip);
//FastLED.addLeds<LED_TYPE,DATA_PIN,CLK_PIN,COLOR_ORDER>(leds, NUM_LEDS).
setCorrection(TypicalLEDStrip);
// set master brightness control
FastLED.setBrightness(BRIGHTNESS);
}
typedef void (*SimplePatternList[])();
SimplePatternList gPatterns = { rainbow, rainbowWithGlitter, confetti, sinelon,
juggle, bpm };
uint8_t gCurrentPatternNumber = 0; // Index number of which pattern is current
uint8_t gHue = 0; // rotating “base color” used by many of the patterns
void loop()
{
// Call the current pattern function once, updating the ‘leds’ array
gPatterns[gCurrentPatternNumber]();
// send the ‘leds’ array out to the actual LED strip
FastLED.show();
// insert a delay to keep the framerate modest
FastLED.delay(1000/FRAMES_PER_SECOND);
// do some periodic updates
EVERY_N_MILLISECONDS( cycle ) { gHue++; } // slowly cycle the “base color”
through the rainbow
if ( digitalRead(PULS)== LOW){
nextPattern();
delay(1000);
}
if ( digitalRead(DOWN_PIN)== LOW){
if (BRIGHTNESS>10) {
BRIGHTNESS=BRIGHTNESS-10;
}
FastLED.setBrightness(BRIGHTNESS);
Serial.println(BRIGHTNESS);
}
if ( digitalRead(UP_PIN)== LOW){
if (BRIGHTNESS<245) {
BRIGHTNESS=BRIGHTNESS+10;
}
FastLED.setBrightness(BRIGHTNESS);
Serial.println(BRIGHTNESS);
}

if ( digitalRead(LEFT_PIN)== LOW){
if (cycle>10) {
cycle=cycle-10;
}
Serial.println(cycle);
}
if ( digitalRead(RIGHT_PIN)== LOW){
if (cycle<245) {
cycle=cycle+10;
}
Serial.println(cycle);
}
//EVERY_N_SECONDS( 100 ) { nextPattern(); } // change patterns periodically
}
#define ARRAY_SIZE(A) (sizeof(A) / sizeof((A)[0]))
void nextPattern()
{
gCurrentPatternNumber = (gCurrentPatternNumber + 1) % ARRAY_SIZE( gPatterns);
Serial.println(“nextPattern”);
}
void rainbow()
{
fill_rainbow( leds, NUM_LEDS, gHue, 7);
}
void rainbowWithGlitter()
{
rainbow();
addGlitter(80);
}
void addGlitter( fract8 chanceOfGlitter)
{
if( random8() < chanceOfGlitter) {
leds[ random16(NUM_LEDS) ] += CRGB::White;
}
}
void confetti()
{
fadeToBlackBy( leds, NUM_LEDS, 10);
int pos = random16(NUM_LEDS);
leds[pos] += CHSV( gHue + random8(64), 200, 255);
}
void sinelon()
{
fadeToBlackBy( leds, NUM_LEDS, 20);
int pos = beatsin16(13,0,NUM_LEDS);
leds[pos] += CHSV( gHue, 255, 192);
}
void bpm()
{
uint8_t BeatsPerMinute = 62;
CRGBPalette16 palette = PartyColors_p;
uint8_t beat = beatsin8( BeatsPerMinute, 64, 255);
for( int i = 0; i < NUM_LEDS; i++) { //9948
leds[i] = ColorFromPalette(palette, gHue+(i*2), beat-gHue+(i*10));
}
}
void juggle() {
fadeToBlackBy( leds, NUM_LEDS, 20);
byte dothue = 0;
for( int i = 0; i < 8; i++) {
leds[beatsin16(i+7,0,NUM_LEDS)] |= CHSV(dothue, 200, 255);
dothue += 32;
}
}

Firmware

The appropriate sketch for the application must be loaded on the Arduino Mega, using a USB cable for connecting to the computer on which we will do the programming. We have provided two sketches that can be found and downloaded here: they are called Demo.ino (it is a series of animations reproduced one after another in order to show the potential of the LED screen) and Tetris.ino (the namesake game). In these pages, we’re only going to publish the Demo.ino sketch for space reasons, which implements an application of the FastLED 3.1 library (or newer versions). The code sequentially executes a series of lighting effects (they repeat every 100 seconds until external intervention, e.g. until the button is pressed) and they rotate. The firmware is derived from Mark Kriegsman’s.

Each lighting effect is managed by a routine and they are rainbow, rainbow with glitter (colored bar and flashing dots), add glitter (flashing dots), confetti (random colored spots flashing and fading out), sinelon (colored dots zigzagging and fading out), void bpm (colored pulsing strips) and void juggle (eight colored dots interest gating).

During execution, by moving the joystick lever up or down you can increase or decrease speed, while by moving it right or left you can speed up or slow down the execution.

Remember that you can upload only one sketch at the time on Arduino Mega (so you have to choose between Tetris and the graphics demo): open it in the Arduino IDE, compile it and send it, then once sent please check if the panel starts to display the lighting effects.

Have fun!

From openstore

ARDUINO MEGA2560 REV3

Joystick Arcade with red knob

STRIP 300 LED RGB ADDRESSABLE WS2812B- NEOPIXEL

Arcade Button – White

SWITCHING POWER SUPPLY 5V DC 130W

Some time ago we had introduced you to the Torpedo switching power supply, a particular kind of DC/DC power supply called SEPIC capable of supplying 5 V from several external supply sources, such as an external voltage between around 3.5 and 20 V, the 5 V coming from a USB connector or the 3 to 7 V supplied by a LiPo battery. The very small power supply also had a circuit capable of charging the battery up through external sources, where available.

The only real limit of Torpedo was the max output current of around 800 mA, which is enough to power small devices and/or prototyping boards like Arduino and Fishino with some onboard shields, but not, for instance, a Raspberry Pi, which requires a current of around 2 A.

By the way, another interesting application of this power supply have been pointed out to us, something we had not thought about: by connecting the input of Torpedo to a solar panel and equipping it with a LiPo battery, we have a virtually infinite power supply, which is very useful for instance in case of remote sensor where replacing batteries or connecting supply cables is very difficult. So this is a perfect Energy Harvesting solution.

Given the resounding success of our Torpedo and the need to have bigger currents, we thought about developing an updated and more performing model; and since we are here, we thought about equipping it with some other interesting additional features.

First of all, let’s take a look at the tech specs of Torpedo 2:

• triple power source: USB, LiPo battery and an external source;
• a wide range of input voltage values: 6,5 – 18 V;
• can supply a maximum current of 3 A;
• high efficiency, even over 85-90%;
• built-in charger for LiPo single cells;
• can switch from battery-powered to another source without interruption;
• 5 V output with high stability when load varies and low ripple;
• possibility to turn off the only output leaving the step-down converter and the charger active;
• possibility to automatically deactivate the output if power supply comes from the USB connector which is limited to 500 mA current by the specs; if there is a battery, power supply is granted by that;
• status LEDs indicating charge, the power supply used, output activation and so on.

Circuit diagram

Let’s start off by saying that, unlike the first version of Torpedo, this new one is not based on the SEPIC architecture for the converter, but we opted for a more common step-up + step-down couple. But why? The main reason is the automatic input source commutation. In the previous model, this took place before the converter using, for efficiency reasons, a MOSFET on the only battery line, in order to avoid voltage drop on a simpler diode circuit. Even the MOSFET shows a voltage drop, which however is not fixed but it depends on its internal resistance (Rdson) and the circulating current. In Torpedo, which is designed for a maximum output current of around 800 mA, the MOSFET current could be estimated with:

Which, considering the values in the circuit, would become:

It was a manageable value, although not negligible. In case of Torpedo 2, things are changing, since we want a maximum of 3 A for the output current, which brings the MOSFET currents to:

That would require a MOSFET characterized by an elevated drain current and low Rdson resistance. On the other hand, by increasing the battery voltage before the selection through a more common step-up converter, we can execute the commutation later, on the 5 V of the output and with a current of 3 A, by using a normal Schottky diode.

So, let’s start our description right from the step-up section used to increase voltage coming from the LiPo battery (protected by the F1 fuse) of 3.7 V up to the 5 V required. This stage is based on an IC by Texas, a TPS5530 with some interesting features, such as an integrated 5 A MOSFET, the possibility to adjust operating frequencies between 100 kHz and 1.2 MHz, a current limitation to protect from overcharges and a complete thermal protection.

The converter works in PWM mode, which frequency is fixed thanks to an external resistance on the FREQ pin; in our circuit, we chose to work on the higher spectrum of the range available, in order to limit dimensions of passive components (inductors and capacitors); work frequency can be obtained with:

With the value of 47 kΩ (R4) used we get a frequency of around 993 kHz, so almost 1 MHz.

The output voltage is regulated by comparing it to an internal reference of 1.229 V; a voltage divider is then used to take that value back to the FB input with the two precision resistances R9 and R10. With the selected values, we find:

Components connected to the COMP input (R5, C12 and C13) are used for compensating the feedback loop and ensure stability of the converter under any load condition.

C7 capacitor on the SS input is used to take advantage of the soft start features of the IC, which allows it to gradually start without unwanted current spikes when it is powered on.

As you can see from the circuit, the high commutation frequency allows to use quite small components, with a small 1.5 µH inductor and tiny, 22 µF ceramic capacitors which are connected in parallel in order to obtain a total of 66 µF with an extremely low ESR capable of providing an excellent voltage leveling on the output.

The last point about the step-up converter is the EN (enable) input that activates it when it is on level high, connected to the UPEN line of our circuit that we will analyze later on.

For a more detailed description of the switching converters functioning in general and step-ups in particular, please see the article in which we introduced Torpedo, published on issue #203.

Now, let’s take a look at the step-down converter used to lower the voltage coming from the input plug Vin through the F2 fuse, which can vary from 6.5 to 18 V (max).

We notice right away the D1 Schottky diode separating Vin line from Vin2 line; it is used to avoid a “return” of voltage found on Vin2 coming from other supply voltages, through the related regulators, up to the Vin input that is also used, as we’ll see later, for automatic source selection.

The converter is based on an IC from Maxim, a NCP3170B, capable of supplying a continuous output current of 3 A and operate at a frequency of around 1 MHz, once again allowing us to use extremely small components. Beware, the model you want to use is the one with the final “B”; the similar NCP3170A works at half the frequency (500 kHz) therefore is not suitable for the passive components we are employing.

In this IC, the control voltage is 0.8 V; we then the voltage divider made of the precision resistors R7 and R8, and using their values we have an output voltage equal to:

In this stage do we see the usual compensation network composed of R2 and C8 related to the COMP input that assures converter stability every under usage conditions.

The converter activation through the EN line (active on level high) is supplied by the VINVALID line that we will see later when discussing the control logics part.

As a final input stage, we see the stage coming from the USB port; the voltage, protected by the 750 mA F3 fuse, flows into VUSBIN line used by the commutation stage that we’ll see later. In order to avoid a return that would invalidate its functioning, we have used once again a Schottky diode (D6) before the commutation MOSFET Q2; this because the MOSFET integrates the usual diode to protect from polarity inversion that allows current to pass between drain and source, therefore the VOUT voltage “returns” on the inputs.

Unfortunately, the diode causes a voltage drop of around 300 mV, which is however negligible in terms of functioning and causes limited losses thanks to the small currents; in fact, let’s not forget that the USB line allows a maximum power absorption of 500 mA by the devices supplied. The commutation MOSFET is controlled by the USBEN line, which also comes from the logic stage we are going to see shortly.

If you’re wondering “how is it possible that a power supply designed to output 3 A use a USB port as a power source?” We can answer that this is possible thanks to a little trick, the USB input is – actually – used only when the current required is not over 500 mA (if correctly activated) or only to recharge the LiPo battery.

Under normal functioning conditions, when the output is activated, the USB source, in fact, is not activated and we switch to the first available one based on “convenience”, i.e. Vin if available or the LiPo battery through the converter.

Only if we are going to use the Torpedo t2o for currents of around 500 mA we’ll be able, thanks to a dedicated bridge, to activate its functioning through the USB line. This may seem a useless feature, but we wanted it in order to allow it to use Torpedo 2 also for small devices in a way similar to Torpedo, by making use of the USB power source.

Logic section

Before taking a look at the actual control section let’s analyze the small linear regulator NCP1117ST50; it is used to provide a low current (a few milliamps) power source for the logics section, and he has to supply it regardless of the power source available.

In order to do so, we are using a linear regulator on Vin2 line, and we take a possible voltage coming from the Vout output or the USB port through the Vusbin we have seen earlier, connected by a power OR gate composed by D2 and D3 diets. Of course, we don’t have high currencies and/or efficiency issues here, therefore the circuit is particularly simple.

Now, here we go with the actual logics section, which is a bit against the flow because it uses discrete components and not a microcontroller that we thought was wasted for this purpose.

As you can see from the scheme, we have used a first part, composed of 6 logic inverters grouped by 2, used for “cleaning up” signals coming from various power sources and the OUT ENABLE bridge, and to obtain the negated values necessary for the commutation logics.

The first 2 inverters work on the VUSBIN line, they control the USBLED LED showing the presence of a USB connection and provide the 2 signals USBVALID e USBVALID as output (one is direct and one is negated) which indicate the presence of a power supply on the USB port. R12 resistor prevents the input from fluctuating, bringing it to ground when the USB cable is disconnected.

The second two inverters work on VIN line, which is capable of reaching 18 V and therefore must be limited to values that can be accepted by the ICs (0-5 Volt), and this limitation takes place through the D5 diode that discharge a possible excess on the power source, and which current is limited by the R11 resistor.

The 3 resistances R11, R13 and R21 also make, combined with the inverters, a simple Schmitt trigger that “switches on” when the input voltage exceeds circa 6.5 V; this in order to avoid that a present voltage although insufficient (< 6 volt) is interpreted as a valid power source. Here, we also have a signal LED, VINLED, and the two phase-opposed outputs VINVALID and VINVALID, required for the next logics section.

A third couple of inverters is not connected to an input but to the OUTEN bridge, which is used to activate or deactivate the power supply output. It can be used, for instance, to insert a power switch that turns off connected devices but leaves the Torpedo on and capable of charging up a possible connected battery. Here, the signal LED can be deactivated through a bridge; it might be superfluous, but in the case of battery power source it allows to save a good 10 mA of consumption.

Now we come to the actual logics section, composed of 4 NAND gates and, in order to save an IC, 2 diode OR gates.

First of all, Let’s see the activation part of the step-up converter, the one related to the U5A and U5B ports and to the D9 and D10 diodes. The converter must be activated, of course, only when there is no alternative power supply voltage available and we want to activate the output. Therefore OUTEN must be at logic level high, VINVALID at level low and USBEN at level low, i.e. their negated values (VINVALID and USBEN) must be at level high. U5A port provides then a low output (UPEN) when OUTEN is high in VINVALID and USBEN are low (or better, when there negated values are high), and a high output in the opposite case. U5B port is used as a simple inverter to obtain the non-negated UPEN value. The LIPOLED LED, which can also be deactivated via a bridge, lights on when the step-up converter is on and when the battery is used as power source.

We can now move on to the second section, the one including the U5C and D7 and D8 diodes; these section’s functioning is quite complicated (as if the previous one was easy, some might say!) And it is used to commutate the USB port power supply. This, as we said when talking about the correlated input stage, must be limited to 500 mA, so in theory Torpedo 2 could not use it. For the same above-mentioned reasons though, we included the possibility to make an exception to that limit using the USBPROT bridge; by closing that, we briefly activate the USB lines’ “protection”, which deactivates it when output is activated, in order to avoid excessive absorption; if you are sure the user will consume more than 500 mA we can open the bridge thus obtaining a functioning which is similar to the previous Torpedo, therefore allowing the load to be powered also through the USB.

Let’s now get back to the circuit functioning, when the output is activated (OUTEN high, OUTEN low), if the USBPROT bridge is closed the USB power source is deactivated, while if the bridge is open the source is activated, provided that (USBVALID is high) and there is no (VINVALID low, or VINVALID).

Next, let’s take a look at the activation section for charging the battery, which is activated only when there is a Vin input voltage (VINVALID high, or VINVALID low) or when the USB source is activated (USBEN high, or USBEN low). In this case too we have a status LED, CHGENLED, indicating if the charge is activated, last but not least, we take a look at the charger, which should be by now quite familiar for us since we have already seen it in the Fishino and Torpedo models, and is based on the ordinary MCP73831. Here with inserted the usual bridge to select charge current (100 mA when open, 500 mA when close) and the recharge LED, CHARGELED, which lights on during recharge and turns off when charging is complete, unlike the previous one (CHGENLED) which is always on when charging is activated, regardless if it’s complete or not.

The Q1 MOSFET is used to activate the charger through the CHGEN we have previously seen. As we have seen, using discrete logics instead of a microcontroller doesn’t make the circuit easier to understand in the very least but it allows anyhow to create interesting functionalities with just “normal” components with no need for programming!

LET’S LAUNCH TORPEDO

In order to activate it we have to:

• insert a bridge on the OUTEN connector to activate the output;
• insert two bridges on the OUTLEDEN and LIPOLEDEN connectors to activate the corresponding status LEDs;
• insert a bridge on the USBPROT connector (recommended) or not if you want to use Torpedo 2 only for loads that require less than 500 mA;
• select charge current of the LiPo battery through the 500 mA bridge, that will have to be short-circuited in order to obtain quicker charging;
• connect one or more power sources to the inputs.

One very last thing: as you can see from the PCB, there are some additional headers, inserted for ease of connection; among these, there is one header for the LiPo battery, if you have a model without the dedicated connector, and output for the same, which can be used to measure voltage through a microcontroller and one Vin header for an alternative connection for the input voltage without using the plot connector.

Watch out for clarity of the LiPo battery, connectors are not standardized and some manufacturers follow a wiring scheme which is opposite of what required by Torpedo 2, therefore… before connecting it, make sure the batteries connector is properly wired, otherwise, your will have to rewire it.

Connecting the battery with inverted polarity inevitably means destroying the integrated step-up and probably some other components too!

With that said, we finish our presentation of our small but powerful switching power supply Torpedo 2, which can be used for various devices, even power-hungry devices like Raspberry Pi, and it will allow you to make those devices portable by taking the power supply from a portable battery pack. Enjoy!

From openstore

Torpedo2 – Universal Switching 3A

It detects humidity through two sensors which are to be used alternatively to let us know when there is water on the ground because it’s raining, or when the water level in a flowerpot is too low and it needs watering.

How can we know the right value of the soil humidity in a flowerpot? Experience surely helps, or we can just wait and see when the plant starts to wilt and dries out: in this case the method isn’t ideal because it would be too late to do something about it, in fact even if we water the plant we might not be able to save it.

Here in this post we show you how, by making use of a really simple circuit, we can provide the two different functions based on the sensor we connect to it: in one case we are going to stick two metal prongs in the ground and check if there’s enough moisture; in the second we’ll have a rain sensor (a wet sensor, in general terms…) that makes use of an inter-digitized electrode printed circuit for the detection.

In the end, the circuit is the same and works by detecting a sufficient quantity of water, like we are going to see in the circuit diagram, in order to trigger a threshold circuit, taking advantage of the intrinsic electric conductivity of mineral water, i.e. common water and  not the distilled kind (which is theoretically an insulator). The difference is that in the first case we need a signal when there is a small amount of water closing the two contacts and in the second one we have a signal when the water level is more than enough.

The rain sensor can be paired with garden sprinklers and water stagnation sensors; irrigating in these cases is pretty useless: when is raining or when it has just finished raining.

Circuit diagram

The circuit is basically composed of a voltage comparator (one of the two contained in the U1 integrated circuit; the other, U1a, has been left disconnected) that allows executing two different functions when the same event is detected; the event is the decrease of resistance value between terminals + and – (A0 and GND), which basically corresponds to the (in the digitized-electrode or fork ) sensor getting in touch with water, when there is enough water to short-circuit the two electrodes of the sensor itself.

The computer also works in non-inverter mode, in that it doesn’t get the reference voltage on the inverter input (6-pin) and want to compare on the non-inverter one; furthermore, there is no feedback, so no hysteresis, therefore the commutation of output from voltage level high to low takes place for the same voltage on the non-inverter input that determines the passage from level low to high.

Since reference voltage applied to 6-pin (inverter input of the comparator) is obtained by a trimmer mounted as a potentiometer, we can adjust the reference at will, from 0 V to full power voltage, and therefore play on the circuit sensitivity in the maximum extent allowed. The comparator is contained in a LM393D, which is a double comparator (so it contains two operational stages specifically designed to function as a comparator) and therefore has an output that can give the maximum possible range, although, when it’s on level low, it doesn’t exactly go down to 0 V (which is a specific aspect of rail-to-rail op amps) but it stays on a few hundred of millivolts. Furthermore, U1b output is open-collector, so it requires a pull-up resistance to reach level high, which in this specific case is the R3, and we have to take note of its resistance value when we put a load on the output by connecting a utilizer that ends up on ground; in this case the voltage that can be effectively picked between the output pin (7) and ground will depend on the current requested, that is the divider ratio, considering that the exact value can be obtained with the formula:

Vdo = Vcc – (Iu x R3)

where Iu is the current at the circuit output, that is by the DO contact (Digital Output, since it provides a digital signal).

If you need to connect the DO contact to a circuit in which input resistance would determine an excessive lowering of the voltage provided, you can decrease R3 value without going below 1 kΩ, because decreasing R3 too much would increase power consumed by the circuit when the comparator output is low level and current passing through 7-pin is enough to raise the corresponding voltage to level low. With that said, let’s see how our circuit works: if we connect a fork sensor between terminals + and – (A0 and GND), a fork sensor composed of a printed circuit shaped with two engraved electrodes reaching almost to the tips, that we are going to stick into the ground, the soil humidity will determine a certain resistance between the two terminals, this resistance will create a voltage divider with R4, connected between Vcc and 5-pin of the U1b. The divider ratio with determine the voltage applied to the comparators input, so, reference voltage provided by the trimmer being equal, the more humidity there is in the ground, the lower the voltage needed for commutation of the comparators output will be.

The latter is at level low (causing the LD1 LED to light on) when the soil is very humid and the resistance is such to keep voltage on 5-pin of the U1b at a lower value than the one applied to the 6-pin by the trimmer; same things apply for the DO terminal.

On the other hand, when the soil starts to dry out, water percentage sensibly decreases and voltage between A0 and GND goes up, until it exceeds the comparator’s reference voltage, causing the output to switch from low-level to high level; now the LED turns off, which means we have to add water. With the trimmer, we can adjust the signal according to the type of soil and the plant we want to monitor, remembering that the more the sensor is near to the ground limit, the more humid the soil must be in order to turn on the LED and vice versa (the LED will turn off way before soil turns to try).

Now, let’s see the circuit functioning as rain sensor: in this case, we are going to connect the dedicated sensor composed of a printed circuit with inter-digitized tracks to the DO and GND terminals (any sensor of this type is good, even if it’s not on a PCB or if it is composed of a circuit printed on fiberglass where tracks are separated by gaps). The functioning, in this case, is the other way around, because we are going to see the LED lighting on when there is water, and water density on the electrodes determines the resistance and the voltage applied at the input of the U1b comparator. So, when water wets the electrodes and short-circuits them and determines a resistance which is the winter of two bring the voltage on A0 to a lower value than the one on 6-pin, the comparator’s output turns off (DO goes high) while when rain stops pouring and water on the terminals dries out, voltage between 5-pin and ground exceeds the voltage between the trimmer’s slider and ground and the output goes back to level high, and the LED turns off. Therefore, in this application the LED is off when there is no rain and it is on when it’s raining; if we use the circuit to signal flooding, the LED turns on when there is water in the ground and it turns off when soil is dry (same thing if we use it as a liquid level detector). A recap of the LED functioning is provided in table 1 for all the application scenarios we can think of.

The circuit can be easily powered with a 9 V battery or even three AAA batteries connected in series; power voltage should be decided also in relation to the circuit functioning; the circuit can also make use of the DO terminal to be for instance interfaced with a microcontroller or a Logics unit. This output can be used for instance inside a greenhouse to monitor plants condition and get a notification when one or more plants require watering (you can create a dedicated PC software for this situation) or detect rain or flooding, or to detect the maximum level of a liquid inside a tank.

Power is signaled by the LD2 LED lighting on (on Vcc+), which current is limited by R2 resistance.

Hands-on realization

If you want to use the system to signal the rain status to a weather station, connect the DO terminal and ground to the input of the station, making sure to check the required voltage and adjusting the circuit power, still within the comparator limits (12 V).

Same thing if you want to connect the circuit to a technological alarm or any other kind of electronic system (even Arduino-based) for data gathering.

The wiring scheme on the following page proposes various application examples and related connections. Interdigitated-contact sensors are placed to the ground and, when it rains, the water will join them together, determining a strong lowering of resistance between the electrodes compared to the dry condition (in this case the resistance is theoretically infinite); by reading the sensor status with a logical input equipped with a pull-up resistor we find a logic 1 on standby, while if the sensor is wet, waters resistance acts as a voltage divider with the pull-up resistor and determines a logical 0. Remember that if you want to detect rain, flooding etc. you have to connect the inter-digitated rain sensor to terminals + and -, while you need the fork sensor to monitor soil humidity in flowerpots. The fork sensor is also useful if you want to create a liquid level detector inside a cistern or another kind of container. Also remember that you can freely adjust the circuit’s sensitivity (i.e. decide the amount of water humidity needed to provide the signal through D0 or LD1 LED) by adjusting the trimmer on the board; to be exact, if you bring the slider near the upper power limit you will need more water, while if you rotate it toward ground you will need only a small quantity of water or humidity.

From openstore

Soil Humidity Sensor

Rain sensor with electronics

Arduino UNO R3

We are going to create a system managed by a smartphone for controlling home appliances and electric devices through Wi-Fi.

Suppose you want to create a system for your home appliances and that you want to create it using a simple solution, a modular solution characterized by a wide array of customization options. Let’s also suppose you want to be able to control it in remote through your smartphone, everything just by writing a few lines of code in the programming language used by Arduino. Thanks to new IOT technologies you certainly do not lack the means to do that and the solution to your problem is at the tip of your fingertips. In these pages will see how to turn your project into reality, by taking advantage of the Fishino UNO board, which has been designed and created in Italy, and which integrates all the functionalities of a Arduino UNO board with the addition of a microSD card reader, a RTC and a Wi-Fi module based on the ESP826 IC. This board is also suitable to realize home automation devices, thanks to its configurable Wi-Fi which allows to easily interact with remote devices.

The project

Let’s suppose we want to manage an electric heater, a fan and a lightning point and we want to measure the temperature of one room; we want to manage the utilizers by turning them on and off at the same time through one or more mobile devices available in our house. In order for everything to function properly we have to have a Wi-Fi router in our house, which would allow communication between the various devices, while Fishino will take care of directly managing the appliances that interface with it. In order to activate a functioning load with mains voltage, the best solution is a relay module, i.e. a board with one low voltage relay and some logics for powering the coil when a certain logic level is received; the relay also allows to switch and commute the high voltage circuit. Everything is electrically isolated by Fishno.

All the necessary to realize our project can be purchased at our store and the related product codes are reported in brackets; here is the full list:

• Fishino UNO board;
• Temperature sensor DS18B20;
• 3x relay module;
• AC/DC adapter.

Everything is depicted in figure  The relay module is a 5 V board equipped with a relay with a coil functioning at the same voltage capable of commuting 10 A current in alternate voltage circuits up to 250 Veff.

In order to connect various parts of the system you can refer to the wiring diagram in figure, showing how to connect a relay module with the home appliance that the module is going to manage; the other relay modules are to be connected exactly the same way, but on 4-pin and 5-pin of Fishino. However.

The – usually open – contact of the relay will be part of the power circuit connected to the mains voltage, therefore you will have to be extremely cautious when you wire up the circuit, given the danger of a 230 V circuit. Connecting the DS18B20 temperature sensor is very easy and all you have to do is disconnect the red powering wire to the 5 V, the black wire to GND and the yellow wire, the signal one, to the input 2 of Fishino. To function correctly, the sensor requires a pull-up resistance equal to 10 kΩ 1/4 W connected between pin2 and pin-5V of Fishino. With the proposed configuration we will be able to activate three utilizer and also measure the temperature in one room.

Now, let’s see how to implement the smartphone control, by taking into consideration the fact that we want a customized interface that has to be responsive and simple to use. We won’t consider a Bluetooth module basically due to the poor rage and the impossibility to send a command from more devices at the same time. On the other hand, we are going to take advantage of the native Wi-Fi connection of the Fishino board, considering that nowadays every household has a private Wi-Fi network, which can act as a bridge between all the connected devices. A first solution would be to implement a Web server on Fishino, which is relatively easy to do, but we would have to bear the inevitable intrinsic latency times of communications with HTML protocol. It is, therefore, preferable to employ a native application capable of guaranteeing virtually immediate execution times; we can find it in the Google Play Store, it is a perfect app for our project because, without having to write a single line of code, it allows us to create our personal interface, that we are going to use in all those projects that require a remote control, the app is called RoboRemo and features an (in-app) editor widget that allows us to create a custom interface and to assign to each element a connection for a remote device.

RoboRemo supports Bluetooth, TCP, UDP and also USB communication, allowing to take advantage of all the available communication peripherals of a mobile device. All the most important widgets for control interfaces are available, we also have the chance to draw charts and send commands at regular intervals; everything is completely configurable without having to write a single line of code.

The reference website where you can find all the details about the application is roboremo;  

you will have to download RoboRemoFree from Play Store (otherwise, if you have an app capable of reading and executing QR-Codes, you can read the code in figure) and install it; the free version is completely free of charge and doesn’t need any kind of registration, but it is limited to five widgets (excluding the menu button and the text fields), which is more than enough for our application. The paid version does not have this limitation.

Once you start the application, you will see a blank work page in which we are only going to find the menu button/, we are going to tap on it and activate the interface creation by tapping edit ui; now we can press any point on the screen and the widget list is going to pop up, from which we are going to select button.

The selected element will be added on the screen; put your finger on the top left corner and drag it (drag-and-drop feature) in order to decide the position, on the other hand, if you put your finger on the bottom right corner and drag it will resize it. Now you can press the button you have just added to open a menu that will let you choose both graphics and functions of the object; we need to set the button text with the set text feature and set the action to execute when you tap on it, thanks to the set press action feature.

The latter will contain text sent to the remote device when the set event takes place. See table for inserting all the sensor’s objects, with the related settings. By default, the string sent will end with the character “\n” which can possibility customize as needed. Even if it seems complicated at first, in a few minutes you will become familiar with the system and you will appreciate how simply you can create an interface.

Once that is done, go back on the main menu and click on don’t edit ui to exit the editing mode; if you want to save your work you can’t use the interface – export feature. The visible text in each button (set text feature) can be edited at will; for all the other parameters, make sure you follow the instructions, at least for now.

The complete user interface of our app will visually appear as in figure:

The next step is writing the sketch for Fishino, in order to coordinate all the operation with the RoboRemo application. First, you have to download and install the drivers and library for Fishino (http://fishino.it/download), you’re also going to need the OneWire and DallasTemperature libraries for this project, these can be managed directly by Arduino’s IDE (from version 1.6.6 onward) by accessing the sketch>library inclusion>manage libraries section.

When everything is ready, you can open the dedicated sketch of this application (the file is called SmartHomeSystems.ino) which is almost ready; the only thing you need to add is the name (MY_SSID) and password (MY_PASS) to access your Wi-Fi network. Fishino must have a static IP address within your network so that it won’t be in conflict with other devices; the value you have to check and possibly reset is at line#define IPADDR 192,168,1,242. This address is important because it will be used by RoboRemo for communication purposes and it has to stay the same; that is why it must be static and not set by the router’s DHCP, otherwise it might change every time Fishino connects to the network, therefore, blocking the connection and the use of the app.

Load the sketch on Fishino and open Serial Monitor to check if it is actually connected to the network, then go back on RoboRemo and, from the main menu, click on connect, then select Internet (UDP) and go on other where you will enter the Fishino address (including the port), which in our example is 192.168.1.242:2390.

The interface you just created remains valid regardless of the communication mode you will set later on, as necessary; remember that you can also set the auto connect function so that RoboRemo will automatically connect when started, with the parameters of the last connection used.

For instance, you can click on the LUCI  button and check on Arduino’s SerialMonitor if messages are being transmitted correctly in the related function is executed; you will be able to see the sender’s address on the screen, that is the address of the smartphone you are using, besides the message sent.

The returned message must appear in the text box of RoboRemo with confirmation of correct execution; if you tap on TEMP, the current temperature will be displayed.

We can describe the essential parts of the sketch in order to allow everyone to add some modifications, because the project can be customized for various purposes. The first part of the problem follows the example FishinoUdpSendReceiveString.ino; we just added the temperature sensor management and the digital outputs. The main cycle basically takes care of waiting for UDP messages to arrive on port 2390 specified in the schedule; once they arrive, they are encoded and made available to the rest of the sketch. RoboRemo sends out a different string based on the action to be executed; in our case, by tapping on one of the four buttons it will sends out the strings TEMP, OUT1, OUT2 and OUT3 (followed by the end character), therefore we only have to identify the string and execute the corresponding command. Anyway, a return message to confirm the message has been received correctly will be sent out. For instance, when we tap on LUCI the “OUT1” a strig is sent and therefore we activate, in toggle mode, the related outputs for the lights (3-pin on Fishino), based on activation or deactivation of the lights, the return message will be “LUCI ON” or “LUCI OFF”, and it appear in the text fields of RoboRemo (see List 1).

Listing1

if(strcmp(cmd, “OUT1\n”)==0) //roboremo light button
{
if (OUT1_status==0)
{
OUT1_status=1;
digitalWrite(OUT1_pin, HIGH);
sendcmd = “LUCI ON\n”;
}
else
{
OUT1_status=0;
digitalWrite(OUT1_pin, LOW);
sendcmd = “LUCI OFF\n”;
}

We’re also going to manage the other two outputs the same way. In List 2, you can see the part of the sketch managing the return process: it basically involves sending out a string starting with the id value of the text field of RoboRemo (id=TEXT) followed by the text to be displayed and ending with the “\n” character. We are going to manage LED lighting the same way by sending out the string “LED 1\n” when it lights on and sending out the string  “LED 0\n” when turning it off.

Listing2

Udp.beginPacket(Udp.remoteIP(), localPort);
Udp.print(“TEXT “);
Udp.print(sendcmd);
Udp.print(“\n”);
Udp.endPacket();

Reading the temperature is just as easy and it requires to identify the TEMP string sent by the related button, then the temperature sensor DS18B20 will read the temperature and then we’re going to compose the return string containing the temperature value (see List 3).

Listing3

if(strcmp(cmd, “TEMP\n”)==0) //roboremo request temperature
{
Serial.println(“Request temperature...”);
sensors.requestTemperatures(); // reading sensor
float Temp=sensors.getTempCByIndex(0);
Serial.print(“Temperature=”); // eco on serial monitor
Serial.print(Temp,1);
Serial.write(176);
Serial.println(“C”);
char tmp[5];
dtostrf(Temp,2,1,tmp); //Conversion from float to string
sendcmd = sendcmd + tmp + “°C\n”;
}

The return string is sent to the IP address of the device which is transmitted last by making use of the

Udp.remoteIP() function, which returns the IP address of the last reception, while it seems that Udp.remotePort() function does not work properly, but RoboRemo waits on the same port indicated for transmission and therefore LocalPort and RemotePort coincide. In our example, the communication port is 2390, therefore both Fishino and RoboRemo are on standby on the above-mentioned port; the only different parameter is the IP address of the sender (this way, multiple devices are able to communicate with Fishino).

This functionality is allowed by using the UDP communication protocol, which doesn’t require a direct connection between a server and a client, in fact all devices are on the same level. The base mechanism for messaging is really simple and well-implemented and therefore is so flexible that it can be adapted basically to any control; besides, on a programming level there are no particular difficulties. Please note that you can display charts and images and the free version is – all things considered – sufficient for small systems, moreover, the flexibility of being able to use both Bluetooth and USB communication interfaces allows for a remarkable flexibility.

From openstore

Fishino UNO

Waterproof DS18B20 Digital temperature sensor

Module 1 relays (mounted)

Switching power supply 5V / 3A micro USB output

Home cinema becomes even more immersive thanks to Raspberry and addressable LEDs: let’s re-create the Ambilight TV effect on any other TV using Raspberry and Kodi.

What’s better than watching a movie in front of your TV in the summer heat or …under a warm blanket in the winter? Once the perfect mood is set, why not enjoy your experience in the best possible way, but the help of technology? Yes, the project described in this article was born with the goal of giving a boost to any modern flat screen TV, from the first models to the latest smart TVs but all their interesting features.

In the early 2000’s, Philips R&D labs designed a system they called “Ambilight” which, using RGB LEDs applied on the edges of the TV, allowed to project colors matching the video content visualized in any given moment on the wall behind the TV.

This technology allowed to bridge the brightness gap between the image on the TV and the wall around it, thus eliminating some known glare and helping the viewer visualizing more details in the image; at the beginning, there was a separate track to manage the film’s color information on the LEDs, but this way, every movie studio would have had to add those tracks to every movie during production phase: the second version of Ambilight would pick up color information directly from the video on screen, in real time.

The screen’s edges are divided into logic sectors, and each sector is associated with a specific LED and, by making a color average of the pixels, you can find the color to set to be reproduced by the LEDs; this operation is repeated for all the LEDs mounted on the TV and all of this is repeated hundreds of time per second in order to provide synchronicity and maximum smoothness to the colors projected around the TV.

With RaspiLight we can re-create this technology and apply it to any flat-screen TV, but there’s more: even when the TV is off, we can control the system through an Android or iOS app and create static or dynamic light effects and make the TV an animated lighting point and not just a simple lighting piece of furniture.

In order to create our project, we need the following components, which you can find on our store:

• Raspberry Pi 3: with Kodi installed it will become a media center, where a program will run in the background taking care of analyzing the edge of the video transmitted and send the information regarding LED colors to Arduino;
• Micro SD: 16 GB recommended;
• Raspberry Pi power supply: 5V 3A recommended;
• A 470 ohm resistor;
• RandA: RandA will be installed directly above Raspberry Pi as a shield;
• A strip of addressable RGB LEDs: 5-m 300-LED strip with control chip WS2812B;
• LED strip power supply: 5V with proportionate current based on length of the LED strip’s Mike on this value must be calculated by adding up the length of four edges of the TV.

As for power supply, consider that, roughly, an RGB LED strip of 5m needs typically a maximum of 8.5 A.

We chose to develop this project using Raspberry Pi 3 because, besides being the most powerful device of the series, it also offers built-in wireless connectivity that translates in an objective advantage when we are going to place it under our TV; in fact, we won’t need to connect an Ethernet cable or an additional Wi-Fi USB dongle.

Moreover, since it also has Bluetooth connectivity, we’ll be able to control our media center in several ways, through Bluetooth keypads and remote controls, with an app from smartphone or tablet over Wi-Fi, or directly through remote control of our TV if it has CEC functionality.

This feature, which is nowadays included in almost any new TV, allows to use the provided remote to control all the devices connected to the TV through HDMI cable (decoder, multimedia players and Kodi media center on Raspberry Pi).

The unique feature of addressable LED strips, which have considerably grown in popularity over the last years, is that we can control brightness and color of each single LED through an associated chip; with this feature, we can create any kind of animation using a microcontroller, an Arduino or a Raspberry Pi.

Applications are many: dynamic lighting, timed effects and, if we place strips one over the other to create a LED matrix, with can also create a PC-controlled, LED maxi screen.

The strips are available with 30, 48, 60 and 144 LEDs per meter, we chose the strips with 60 LEDs per meter to have a good correspondence between the video on TV and the colors projected on the screen; this because by choosing a strip with a bigger distance between each LEDs, we would have had color “gaps” and the end result wouldn’t have been optimal, while on the other hand, with 444 LEDs per meter, LED density for each single sector would have been uselessly bigger, increasing power consumption of the whole system and creating lighting hues we wouldn’t even be able to perceive.

SOFTWARE

The pieces of software we are going to employ are basically four: Kodi (which we have already talked about in issue #201 in the article on the Raspberry Pi Media Center), HyperCon, Hyperion and a sketch for Arduino.

Kodi

This is a program we are going to install on Raspberry Pi in order to turn it into an actual media center, capable of playing full HD video content, photos and music; everything is connected to our home network so that sharing multimedia content to display them on TV is quick and easy.

HyperCon

This program will run on our PC, we’re going to indicate the number of LEDs on the sides of our TV and other parameters that we will analyze in-depth later; these will be used in order to create the config file that will be uploaded on Raspberry Pi.

Hyperion

This program will be installed on Raspberry Pi and will run in the background every time Kodi is launched; its task is to analyze the sectors on the edges of the screen and send out LED colors for all the strip through a serial connection to Arduino or RandA.

Sketch

We will upload a simple sketch on RandA (our Arduino board interfacing with Raspberry Pi) that will take care of receiving information from Raspberry Pi and assign colors to the LED strip attached to it; before uploading this sketch we will modify a few parameters to adapt it to our system.

Besides these four programs, we are going to use another configuration software, Boblight Configurator, that will allow us to calculate the prefix of our LED strip: “prefix” is a series of hexadecimal numbers that depend on the number of LEDs we have for each side of our TV; we are going to insert this parameter in the sketch before uploading it on RandA. These way, the strip will be recognized and Hyperion and Arduino will be synchronous during serial communication.

There are several software’s just to analyze the various video sectors during reproduction and assign colors to the LED strips lining the screen, the most famous are Boblight and Hyperion; we went with Hyperion because it has some advantages: the code is much more optimized, since the lag (LAtency Gap) between video and LED coloring is zero (Boblight has almost 1 second delay, in many cases). Besides, the whole system is much more comfortable, allowing us to fine-tune it and calibrate LEDs’ colors, control LEDs from the PC and app for smartphone and execution of lighting animations even when the TV is off.

Then, we are going to use the Boblight system configurator only to calculate the “prefix” parameter to write in the sketch, because Hyperion configurator does not offer this feature.

REALIZATION

Now, let’s take a look at the practical side of the project, which involves preparation of hardware, wiring, installation and configuration of the corresponding software.

Let’s start from assembling the electric and electronic part, for which you have to follow the diagram in figure , keep in mind that in this application we are using Raspberry Pi as the brain and our RandA (Raspberry and Arduino) board to interface with the LED strips. For those of you who are still not familiar with it, RandA is the hardware we have designed and developed, which is inserted in the Raspberry Pi and gives us the possibility to use Arduino hardware and the white range of ready-made libraries offered by the Arduino world for controlling standard devices (e.g. LED strips).

With that said, let’s go back to wiring and elements layout: if we look at the rear panel of our TV we are going to apply our LED strip with its adhesive tape, starting from the bottom left half (if the TV has a central stand), then we continue in clockwise direction along the left edge, the top edge, right and in the right part of the bottom edge.

When we get to each corner, we have to cut the LED strip and connect it to the next segment using pieces of wire we are going to solder in the corresponding pad using a soldering iron no more powerful than 25 W to avoid creases on the strip; once we complete the perimeter, we cut the excess strip following the precut line on each one of them.

Now, let’s connect the two biggest wires of the strip (the black and red ones) to the 5 V power supply, which must be capable to supply a current calculated based on the total length of the LED strip applied on the TV and remember what we said above, that is that 5 m of strip absorb around 8.5 A, therefore if total perimeter is 2.5 m, the current needed will be 4.5 A etc.

Then, we are going to connect the GND contact of the strip to the GND of RandA and the strip’s data wire one of RandA’s pins (we chose 6-pin…) Placing a 470 Ω resistance in the middle.

Let’s take note of how many LEDs we have for each side of our screen and the total number of LEDs: we are going to use these values in a short while when we are going to configure Hyperion (values indicated in images refer to the TV we have used for the project).

After mounting the whole electronics part, let’s download the Hyperion configuration program on our PC (that we can see in figure from this webpage.

Once launched the program, we can see in the main screen all the parameters needed to create the config file; pay attention to the preview image: the front side of the TV will be displayed, while we always have to think as if seeing the TV from the rear side (just like during application of the LED strip).

Here’s the parameters for the “hardware” board:

• Configuration name = this is used to give a name to our configuration;
• Type = Adalight;
• Output = /dev/ttyUSB0;
• Baudrate = 500.000;
• Delay [ms] = 0;
• RGB Byte Order = GRB;
• Direction = counter clockwise;
• LEDs horizontal, left, right = here we are going to insert the specific values for our TV;
• Bottom gap e 1st LED offset = we are going to play with these values to adjust LED interruptions in the bottom edge in case the TV has a stand supported and place the first LED in the correct position.

As for the other boards, we only have to make sure that “Internal frame grabber” and “Kodi Checker” are enabled; we can export the config file JSON with the button “Create Hyperion Configuration” and keep it ready for later when we are going to need it.

Now, let’s download the Boblight configurator (the related screen can be seen in figure  from this website.

Let’s open the program and set all the values of the LEDs on the edges using the fields: Top Row LEDs, Right Col LEDs, Left Col LEDs, Bottom Left LEDs, Bottom Right LEDs and Bottom Center Padding; since we have mounted our strip clockwise, in the field Orientation (Rear View) are going to select “Clockwise”.

Let’s now finish the configuration inserting the parameters in the lower part of the program screen:

• Name = this is just to name our configuration;
• Output Device = /dev/ttyUSB0;
• Type = mono;
• Baudrate = 500000;
• enable “Use Magic Word” and we are going to write Ada;
• set Interval to 100000;
• set Open delay to 1.

As you may have noticed, the field “Prefix” fills automatically after we insert all the data; unfortunately, the displayed value is not correct, because Boblight counts LEDs starting from number 1, while Hyperion starts counting from number 0.

In order to generate the exact prefix we have to decrease total number of LEDs by one (we can do it, for instance, by acting on the field “Bottom Left LEDs” and decreasing it by 1): this way, the field “Prefix” will be calculated correctly.

Let’s take note of the Prefix and close Boblight e HyperCon configurators which, if everything goes right, we are not going to need anymore.

Now we are going to download the Arduino’s sketch from this website.

We will open it with Arduino’s IDE and edit the header values:

• STARTCOLOR = starting color, set went Arduino is powered on but it has no color information coming from Raspberry Pi;
• BLACK = black setting;
• DATAPIN = Arduino or RandA pin twitch LED strip data are connected (in our example it’s 6-pin);
• LEDCOUNT total number of LED that we have installed and counted;
• SHOWDELAY = set this field to 1;
• BAUDRATE = set to 500000;
• BRIGHTNESS = max brightness level of the LCD strip, to be set based on the average brightness of the environment where we have our TV (in our example we set it to 100);
• prefix[] = we are going to replace its value with the one generated by Boblight, for instance 41 64 61 00 B8 ED would become 0x41, 0x64, 0x61, 0x00, 0xB8, 0xED.

We are not going to touch the rest of the sketch which, as you can see from Listing 1, waits for the incoming prefix coming from the Raspberry Pi’s serial port and, once obtained, if it matches the one set internally, it keeps “listening” for color data to set on each single LED.

Listing1

#include “Adafruit_NeoPixel.h”
#define STARTCOLOR 0x333333
#define BLACK 0x000000
#define DATAPIN 6
#define LEDCOUNT 185
#define SHOWDELAY 1
#define BAUDRATE 500000
#define BRIGHTNESS 70
const char prefix[] = {0x41, 0x64, 0x61, 0x00, 0xB4, 0xE1};
char buffer[sizeof(prefix)];
Adafruit_NeoPixel strip = Adafruit_NeoPixel(LEDCOUNT, DATAPIN, NEO_GRB + NEO_KHZ800);
int state;
#define STATE_WAITING 1
#define STATE_DO_PREFIX 2
#define STATE_DO_DATA 3
int readSerial;
int currentLED;
void setup(){
strip.begin();
strip.setBrightness( (255 / 100) * BRIGHTNESS );
setAllLEDs(BLACK, 0);
setAllLEDs(STARTCOLOR, 5);
Serial.begin(BAUDRATE);
state = STATE_WAITING;
}
void loop()
{
switch(state)
{
case STATE_WAITING:
if( Serial.available()>0 )
{
readSerial = Serial.read();
if ( readSerial == prefix[0] )
{ state = STATE_DO_PREFIX; }
}
break;
case STATE_DO_PREFIX:
if( Serial.available() > sizeof(prefix) - 2 )
{
Serial.readBytes(buffer, sizeof(prefix) - 1);
for( int Counter = 0; Counter < sizeof(prefix) - 1; Counter++)
{
if( buffer[Counter] == prefix[Counter+1] )
{
state = STATE_DO_DATA;
currentLED = 0;
}
else
{
state = STATE_WAITING;
break;
}
}
}
break;
case STATE_DO_DATA:
if( Serial.available() > 2 )
{
Serial.readBytes( buffer, 3 );
strip.setPixelColor( currentLED++, buffer[0], buffer[1], buffer[2]);
}
if( currentLED > LEDCOUNT )
{
strip.show();
delayMicroseconds(SHOWDELAY);
state = STATE_WAITING;
currentLED = 0;
break;
}
break;
}
}
void setAllLEDs(uint32_t color, int wait)
{
for ( int Counter=0; Counter < LEDCOUNT; Counter++ )
{
strip.setPixelColor( Counter, color );
if( wait > 0 )
{
strip.show();
delay(wait);
}
}
strip.show();
}

Now, we are going to compile and upload the sketch on RandA. Since the RandA board is directly installed on Raspberry Pi everything is more compact. It requires Raspbian operated system to be used with the preconfigured RandA on which we are going to install Kodi.

We will install Hyperion and upload the configuration file JSON previously created on our PC.

HYPERION AND RANDA

Now, let’s download the two-part disk image for RandA:

• RandAV1.5-Raspbian-jessie-2016-05-27-p.zip.001
• RandAV1.5-Raspbian-jessie-2016-05-27-p.zip.002

We are going to unzip the two images and merge them together using a program such as 7-Zip and copy them on a suitable microSD memory card, then we are going to insert the card in the Raspberry Pi’s reader, then power time.

Once the operating system is launched, let’s connect via SSH the program like MobaXTerm and launch the following command:

sudo apt-get update

Next, we are going to install Kodi:

sudo apt-get install kodi

We set Kodi’s autostart by editing the settings file:

sudo nano /etc/default/kodi

Let’s set ENABLED to 1, user=pi e NICE=-10; now we close in save with CTRL + X, then Y and ENTER.

Now we download Hyperion:

sudo wget -N https://raw.github.com/tvdzwan/hyperion/master/bin/install_hyperion.sh

Let’s install it:

sudo sh ./install_hyperion.sh

We are going to transfer, using MobaXTerm or WinSCP, the configuration file JSON (named “hyperion.config.json”) up Hyperion in the path:

/usr/share/hyperion/config/.

Let’s edit it using the command:

nano /usr/share/hyperion/config/hyperion.config.json

And replace the field corresponding to the serial port “/dev/ttyUSB0” with RandA’s one, “/dev/ttyAMA0”. Once finished, let’s close in save using CTRL + X, then Y and ENTER.

Now we are going to edit the startup file for Kodi and also insert the automatic launch for Hyperion:

sudo nano /etc/init.d/kodi

We are going to locate the following code section:

case “$1” in

 start)

   [ “$VERBOSE” != no ] && log_daemon_msg “Starting $DESC” “$NAME”

   do_start

   case “$?” in

     0|1) [ “$VERBOSE” != no ] && log_end_msg 0 ;;

     2)[ “$VERBOSE” != no ] && log_end_msg 1 ;;

       esac

Between “do_start” and “case “$?” in” we are going to insert the line below:

/usr/share/hyperion/bin/hyperiond /usr/share/hyperion/config/hyperion.config.json

Now we close in save using CTRL + X, then we press Y and ENTER.

We are now going to mount RandA on Raspberry Pi, we upload Arduino’ sketch using the command ArduLoad or with Arduino IDE preinstalled; then we are going to turn off the Raspberry Pi, disconnect the power supply and reconnect it to RandA: Kodi media center will automatically launch, the animation with the rainbow colors will be displayed and your system is up and running.

In this case, on our website you can download the ready-made image for Raspberry Pi with RandA: all you have to do is change Hyperion’s configuration and the sketch values of RandA in order to use it in our application.

TROUBLESHOOTING

If, after launching Kodi, you don’t see the lighting effect with the rainbow colors, it means that Hyperion cannot communicate with RandA; there are mainly two possible reasons for this: a wrong baud-rate value (on the sketch or on the configuration) that, allow us to remind you, must be set to 500000, or a wrong prefix.

In the first case, you need to reopen Arduino’s sketch and the configuration window of Hyperion and check that the two baud-rate values are the same; in the second case, on the other hand, you need to reopen Boblight configurator and set all the values in order to generate the prefix, and remember that you need to take off one LED from one of the sides in order to get the correct prefix. Once done that, insert the prefix in Arduino’s sketch and upload it. Reboot your Raspberry Pi after every modification of the configuration file or the sketch and, if it still doesn’t work, carefully go over all the configuration parameters inserted in HyperCon and make sure they match exactly those found in this article.

SYSTEM CUSTOMIZATION

In some cases, you might want or need to adjust the colors of the RGB LEDs in order to make the lighting outline identical (in terms of color) to the one determined by the colors projected by the screen of your TV; in order to adjust the color you can open HyperCon, go on the “Process” tab and change the value in the “Color Calibration” section: with each modification you will need to generate the JSON configuration file again and then copy it on the Raspberry Pi. You can also launch an SSH connection to Hyperion directly from HyperCon; for this you need to go on the “SSH” tab and set here your connection data (system, IP, port, username and password) and then click on “Connect”. Once you establish a connection you can send the configuration file directly from this program and change the LED colors in order to check that they actually match after calibration. On the other hand, on the “External” tab, you can change settings for that part of Hyperion connecting to Kodi and analyzing video, you can enable or disable the LEDs in the various program sections such as manual, video, screensaver…

If you scroll down, in the “Booteffect / Static Color” section, you have the possibility to change the effect or the static color executed when Hyperion connects to Kodi (with each launch): as default we will find the rainbow-colored animation, with its duration. Well, with that said we can call it a day; all we have left to do is hope you will enjoy this project!

From openstore

Raspberry Pi 3 Model B with Wi-Fi and Bluetooth

Strip 300 LED RGB addressable

SWITCHING POWER SUPPLY 5V DC 130W

Arduino Nano V3.1

RandA: the union from Raspberry and Arduino

A virtual shield and a smartphone, with the addition of ultrasound sensors that allow us to detect passage and direction of anyone crossing a passage.

Most of Arduino’s success is also due to the fact that the base features of this board can be expanded by simply adding shields, which are boards containing hardware that is specific for each application. The possibility to add new hardware on the existing base board also provides almost countless development options and encouraged the most important manufacturers of components and electronic devices to propose an innovative and interesting solution.

Do you want satellite localization? Add a shield with a GPS receiver! Do you want an application with a graphic display? All you have to do is add a shield with a GLCD (Graphic Liquid Crystal Display). Nowadays, for each function, there is a dedicated shield, which is commercially available in numerous options based on the manufacturer. In this scenario, the team of Integreight had an absolutely genius idea, thinking about the potential of interaction between an Arduino board and a recent smartphone.

Actually, many functions carried out by the shield are already present in a smartphone, which is well equipped in terms of built-in sensors; besides, it has a sophisticated communication section ranging from Bluetooth to 3G. Finally, in integrates a high-res display. Well, Integreight team thought that every feature of a smartphone could be represented on a shield for Arduino; all they had to do was establish a communication with Arduino and they were set. That’s where the idea for 1Sheeld came from, that is a unique Arduino shield that allows taking advantage of all the features of a smartphone; the pun is intended and it indicates that it’s just one single shield for many functionalities.

So, if we need satellite localizer in our project, instead of buying a specific shield, we can take advantage of the GPS receiver of the smartphone, and when we need a graphic display we can use the smartphone’s one. Naturally, communication sections and support for sending emails, SMS or excessive social networks is also available for our applications.

In total, Integreight was able to implement more than 40 virtualized shields with 1Sheeld; the complete list is available here.

1Sheeld is composed of two hardware blocks, one being the smartphone; the other one is a specific interface shield based on an Atmel ATmega162 microcontroller and a Bluetooth module that is simply used to allow our Arduino board to communicate with the smartphone. The biggest effort by the developers was to develop an application to run on the smartphone, trying to obtain a very user-friendly product that has at the same time the maximum operational flexibility possible to allow the user, with just a few taps on the display, to customize the desired interface. The Bluetooth shields interconnect Arduino to a smartphone, where the active application initializes and uses the sensors required, which act just like they are on Arduino and can be accessed anyways; this is remarkably convenient.

Unique shield and virtual hardware

Now, let’s take a more in-depth look at this product and how it can be employed, by also making use of the electric diagram illustrated in the previous pages. 1Sheeld is proposed as an absolutely standard shield for Arduino Uno/Arduino Mega. Its power voltage can manually be set to 3,3 V or 5 V through the POWER-SW deviator, which allows the shield to also function with 3.3 V boards, provided their pins are compatible with Arduino. Anyway, the shield’s logics also works with voltage picked by the deviator’s slider: when POWER-SW is 5 V, the U1 regulator takes the 3.3 V necessary for the Bluetooth module, which has to work at 3.3 V., The board uses a standard Bluetooth module (Bluetooth 2.1) labeled BT-HC06 in the electric diagram, allowing it to communicate with a smartphone up to around 10 m distance.

The Bluetooth module is normally reset through R7; using the Q1 MOSFETs, when the microcontroller puts its PE0 line to a logic level high, the RST terminal of the module goes low and reset is deactivated. The UART inside the Bluetooth module is interfaced with the virtual serial implemented in U2 by PB2 and PB3 I/Os and through two 74LVC1G125 buffers used as level adapters when the shield works at 5 V: in this case, in fact, PB3 line of the microcontroller provides TTL impulses that are adapted to 3.3 V by the IC1, while the module’s UTX provides 0/3,3V impulses which are then translated to 0/5V by the IC2.

1Sheeld communicates with the Arduino board using the internal UART module, therefore we want to be able to use the Serial Monitor feature of Arduino while it’s working. PIO1 line of the Bluetooth modules drives, through the R3 resistor, the BT-LED providing signals on connection activity.

In order to allow Arduino to be programmed by PC, the shield has the UART-SW deviator that allows excluding communication between Arduino’s UART and 1Sheeld. The LEDs labeled TXD and RXD (pins PA6 and PA7 of the micro U2) regulate the activity on the serial port.

On the board, there is also a reset button that replicates the functionality of the reset button on the Arduino board.

Now, let’s see how to activate this shield: first things first, we have to go on the reference website where we can find a section dedicated to tutorials and one dedicated to community projects. The first step is to download the Arduino library, that can be found under the Download page; we can also use the dedicated tool provided with the latest version of the Arduino’s IDE (version 1.6.7 or later) and go to sketch> library inclusion> library management and then select onesheeld and install it ; all the sketches in this post refer to version 1.8.0 of the library.

You can get to know the shields right from the start by trying out the numerals sketches already available in the examples.

OUR PROJECT

In this post, we propose instead a general utility application, a people counter. If you don’t know what this is, we can tell you it’s a system capable of detecting both the passage of people through an opening and the direction of said passage; this way we can have both a visual and acoustic indication of the passage and specifically count who goes in and who goes out in order to verify a possible difference and understand if someone is still inside a business establishment after working hours.

So, our application can be useful for the business owner in order to receive an acoustic signal on his or her smartphone to know if someone enters the shop when the owner is in the back; but it can also be a simple way to count people going in during a trade show or an event, everything on a device that we don’t always have to remember picking up or adding to our equipment because it’s always with us.

We have also designed a domestic application because we can also use our project to know if someone enters in a room or to know if your child has just trespassed a forbidden zone, the applications are really countless.

However you choose to employ it, the most interesting part of the project is that the information related to the passage of a person is directly provided on your smartphone, along with an indication of a number of people passed through and a vibration and acoustic modification.

We provided two options, one if you just want to know the number of people passing and one if you want to keep a record of people going in and out. So, let’s suppose there is a passage and we want to count people crossing it, we could’ve also used some photoelectric barriers and run the wires to the transmitter and the receiver from both side of the passage, on the other hand, in this project we wanted to use some simple (and cheap) ultrasound sensors capable of identifying the passage of people based on the distance measured.

As a sensor, we have used the affordable MISDIST04 which is an ultrasound meter with a 1 cm precision from a distance of a few meters. By placing this sensor on a door jamb facing the opposite door jamb, based on the measure provided by the sensor we will be able to evaluate if a person or an object has crossed the passage.

In the figure you can find the electrical wiring needed.

As for powering the system, we recommend using a small switching, high performance 5 V output power supply and a type B USB email port compatible with Arduino. You can power Arduino also through its plug connector provided you use a power supply with a voltage between 7 and 12 V, better if it’s a switching power supply for higher performances, such as a 12 V switching power supply available in our store with code AL12V1A2.

The technique used for this application involves reading the measure provided by the sensor at set intervals and comparing it with the previous measure: if the measure provides a sensibly reduced value, it means that an object passed in front of the sensor. For better accuracy, we are going to discard all the measures considered unreliable, such as those less than 10 cm and over 150 cm; moreover, we are going to prevent successive readings for a prefixed period after deducting the crossing of one person.

The core code lines, in this case, are those setting the parameters described above, which are the working parameters of the sketch:

long maxDistance=150;

long triggerDistance=50;

long deadTime=1000;

Where maxDistance represents the maximum reliable measure, over that value the reading is discarded, while the triggerDistance parameter indicates the measure’s limited variation besides which we consider that a person certainly crossed the passage; deadTime parameter is inhibition time between one reading and the next one, which is useful in order to avoid that fluctuation in distance measured lead to errors when detecting the crossing of a person. The program section referred to counting passing people is listed here.

Listing1

inUS();
if ( currentDistance>10 && currentDistance < maxDistance)
{
if (previousDistance-currentDistance > triggerDistance && millis()-triggerTime > deadTime)
{
triggerTime=millis();
count++;
-> gestione 1sheeld <-
}
previousDistance=currentDistance;
}

The inUS() function is used in order to read distance measured by the sensor; correspondent value is then placed in the variable currentDistance. Only when the crossing of one person is detected, the variable count is incremented by one. During our tests, in order to display this value on the PC we used a virtual serial port implemented but they library softSerial which data were sent to the DC through a USB/serial converter; this because when 1Sheeld is active the UART module of Arduino cannot be used to communicate with the personal computer.

Now, let’s get to the more interesting part, how to integrate 1Sheeld’s features in this project. In order to make everything ready we have to work on the smartphone side and first of all we’re going to install the official 1Sheeld application directly from Google store on Android.

The app can also be downloaded from your web browser by visiting the page download where you can get the Android version and libraries.

Next, let’s activate the smartphone’s Bluetooth functionality (if it’s not already activated) and launch the app: first, the app will ask us to detect 1Sheeld (figure shows the research app for 1Sheeld devices via Bluetooth);

then we will have to connect (figure shows the screen once a connection is established).

Now we can choose the suitable virtual shields for our application:

since we want to see the tally on the smartphone’s display, we need an LCD Shield;

we also want an acoustic notification with each passage, so we are going to use a Buzzer Shield.

Next, we want to be able to manually reset the tally, so we can use a Button Shield ;

finally, we want to implement a light vibration, therefore we select the Vibration Shield.

In case we want to use the system in order to detect intrusions or unauthorized passages, we also have the chance to send a notification to the smartphone using a dedicated Notification Shield.

In Listing2 we report the code lines to include the 1Sheeld library and enable the functionalities requested. As suggested by the developers, it’s recommended to only enable (via the command #include) the shield you are going to use, in order to save energy. In Listing 1, under the voice “1Sheeld management” we are going to insert the program lines that allows to interact with the smartphone.

Listing2

#define CUSTOM_SETTINGS
#define INCLUDE_VIBRATION_
#define INCLUDE_LCD_
#define INCLUDE_BUZZER_
#define INCLUDE_PUSH_BUTTON_
#define INCLUDE_NOTIFICATION_
/* Include 1Sheeld library. */
#include <OneSheeld.h>

As you can see in Listing 3, the lines allowing to send data to the smartphone are really simple and basically are a call to the decide function.

Listing3

Buzzer.buzzOn();
Notification.notifyPhone(“Someone pass!”);
LCD.clear();
String stringOne = String(count, DEC);
String dataText = “Count= “ + stringOne;
char charBuf[16];
dataText.toCharArray(charBuf, 16);
LCD.print(charBuf);
delay(50);
Buzzer.buzzOff();
Vibration.start(1000);

In order to display the numeric value, however, we have to convert it into a char array; other than that, instructions are pretty intuitive.

Some functions can be omitted as needed, e.g. notification is useful only in case of occasional although important passages, however, it has the advantage to let us know the exact time when the crossing took place. The tally reset management is operated by the following code lines:

 if(PushButton.isPressed())

 {

   count=0;

   LCD.clear();   

   LCD.print(“Count= 0”);  

 }

As you can see, tally reset management takes place by reading the status of the button implemented in the smartphone.

LET’S GET TO WORK

Very well, now that we have established how the firmware works and how we can work from the app, let’s get to the core of the project: on the application main screen, all we have to do is tap on the icon on the left to include the shield in the project; by clicking on the shield icon in the top right corner we will start the communication with the shield and system will be operative: really simple and intuitive!

In the shield, the blue LED called BT-LED will go from blinking to steady to indicate that communication has been activated and the system is ready. You can select it by swiping the shield you want, passing from tally visualization to volume regulation for the buzzer, to a screen where you will find the button to reset the tally value.

DETECTING PASSAGE DIRECTION

For specific applications, we thought about a system variant that involves using two ultrasound sensors placed at a distance of around 25 cm one from the other. This way, upon the passage of a person one sensor, will be activated first and then the second one, and the sequence depends on the direction; this way, we can understand if the person is going in or out. In other words, the ultrasound sensors will detect an increase and a decrease of distance from the body of the person in sequence.

Taking figure as a reference, we can say that a person going in will first encounter sensor 1 and then sensor 2, vice versa the person will first encounter sensor 2 and then sensor 1 if they are going out. All we have to do is check both sensors and memorize which one provided the signal first, then wait for the signal from the second sensor in order to determine if the person is going in or out; the functioning principle is really similar to the one used by rotation encoders to determine rotation direction of a knob.

Of course, if the second reading doesn’t arrive within a prefixed time period, the system will decide that the person has not crossed the passage completely and therefore will not count them.

The sketch written for this variant of the system is called contapersone2US.ino and the visualization on Serial Monitor of debug data is available in the previous figure; the result on the smartphone’s display can be seen in the figure , showing us the representation of alphanumeric virtual display implemented by the LLC Shield.

In this last case, since we have implemented it, passage direction can also be indicated, meaning if the subject is going in or out; the tally will increase by one if the person is going in and will decrease by one if the person is going out.

By placing such a system at the entrance of a room we will be able to know the number of people inside, of course with some limitations which are due, for instance, to more people overlapping or disturbances of various nature due to clothes flapping in the air because of air gusts or strong ventilation in the room. In fact, the system cannot detect the simultaneous crossing of more people, in that if there is no space between the one in the front and the one in the back, only one passage will be detected.

Conclusion

We conclude here our analysis of 1Sheeld and a couple of applications made possible by it.

We think we managed to make you understand, in these pages, the potential and the features of the product, so much so that you can easily imagine what applications you can implemented by taking advantage of the numerous virtual shields you have at your disposal, especially those hard to implement with a classic hardware shield for Arduino, for instance the message sending through social networks (which would require a Wi-Fi shield and a lot more hardware) or vocal recognition. With 1Sheeld, on the other hand, you can immediately use a Voice Recognition Shield to identify vocal commands, or a Camera Shield to acquire and analyze video clips.

In conclusion, based on what we have explained, you can experiment by yourself on the possibilities offered by a solution portfolio containing over 40 virtual shields.

Enjoy!

From openstore

Switching power supply 12 V-1,2 A

Arduino Shield for Android smartphones

Ultrasonic range finder 2-450 cm