Short Circuit - Part 2

I finally managed to stack up the robot i have been building. The completed assembly is shown in the photo below. The robot can be remotely controlled as far as the NRF24L01+ with PA can allow and can transmit video over a WiFi connection. Video transmission is therefore limited to the range of the WiFi signal.

This article is a follow-up to a previous one that you can find here. Read this First !!!

[1] The foundation of the robot is a Zumo robot shield from Polulu containing the power source - batteries, gyro etc. 

[2] The zumo motors are controlled by an arduino clone called Entuino from Entesla. I had this board modified such that the header pins stick out of the bottom of the board so that i could mount custom shields on top of the main board. The DC jack had to be de-soldered too. This processor runs a state machine that controls the motors based on commands it gets from [3]

[3] I designed a custom board to mount the Teensy 3.1 ARM Cortex M3 module from PJRC. This board was stacked on top of the Entuino. The purpose of this board is to communicate with the NRF24L01+ 2.4 GHz radio transceiver and send the commands down below to the Ent. This board will also process the data obtained from the gyroscopes on the zumo shield. The reason behind using the Teensy was to offload the communication and computing from the ATMega, as it has more features and memory and use the Ent only for motor control.

As seen below the plastic mount is fastened to [3] using M3 bolts and slots cuts in the board & rests on header pins. I could have removed the pins but that would render the board useless for any other future projects. Hence, bob's your uncle....go figure...

[4] The last board on the stack is the RaspberryPi. It's sole purpose is to provide camera data over Wifi. On power up a remote login is made over wifi to access the RPi terminal, from the terminal a VNC server is started. Using a windows VNC client like TightVNC the remote VNC session is accessed providing the RPi desktop. Once on the desktop the camera can be accessed using OpenCV. The motion of the robot can now be controlled using another arduino with a NRF24L01+ connected to the PC serial port and you can view where the robot is going using the WiFi VNC session. There is a minor N/W delay in viewing the video over VNC.

I had to design a custom 3D printed part to mount the RPi board and it's camera. The part was printed using my FabX 2.0 printer. Some slots had to be cut out in board [3] using a dremel to mount the M3 bolts to fasten the 3D printed mount. The part went through several iterations to get the dimensions, thickness and placement right.

Design Iteration 1: The one on the left was too thin and bent under the pressure of the bolts given that the bolts did not align properly to the RPi holes due to inherent 3D printer drifts. The camera mount was totally miscalculated.

Design Iteration 2: The one in the center turned out fine but the camera mount slot turned out too wide because of a small dimension miscalculation in SolidWorks. Additionally the through-hole components of the RPi were causing misalignment when the fastening bolts were tightened. I removed some material from the center of the base plate and filleted the corners to speed up printing and use less filament.

Design Iteration 3: The one on the right turned out perfect but the camera mount had the same problem of not going into the slot enough. Though it was a tight fit, the camera was resting on the components on the bottom layer of the camera board which was not good. I would rather prefer to rest it on the camera edge cable connector.

Design Iteration 4: The one at the bottom and the last one finally turned out to be just right. The RPi mounting holes were extruded above the base plate to give a flat mount with a support at the end of the base plate, this prevented any through hole components from touching the plastic.. The camera mount was extended to the bottom and some material was removed such that it went right through the slot and came to rest on the edge connector. Instead of using holes i replaced them with rounded slots so that the bolts can be aligned properly with the mounting holes on the RPi to correct for drifts in intended design by the printer.

The above design can be found on my Thingiverse along-with other stuff.

A lot of mods have been planned to keep the stacking of boards to a minimum and have everything controlled using the RaspberryPi in the near future.

Short Circuit - Part 1

I've  got my hands on the Zumo 1.2 robot and it's time to do some crazy stuff with it. Last month i finished designing a customized baseboard for the Teensy 3.1 Cortex-M4 board by PJRC. This baseboard was tailored specifically for the Zumo. More details on the Zumo 1.2 can be found here. The zumo is designed such that it acts as a shield for the arduino uno board. However if you mount the standard original arduino on the zumo, you cannot mount other shelds. Some pins are specific to the Zumo which you can check on the Zumo wiki. Some of my friends who are founders of Entesla managed to give me one of their arduino clones - the Entuino with all the headers removed. I soldered the new headers as per my convienience, removed the DC jack and reset switch and it looks like this.

When mounted on the Zumo the board looks like this. Now i can mount an infinite number shields on top of this board (conditions apply....even mathematically :P)

Notice that few of the pins have been cut off such that they do not interfere with the shield on top. These are primarily the controls for the zumo motors that were mapped to the same pins used by SPI. The power pins too were not made available to shields above the entuino. The Teensy board has its own voltage regulators for 5V and 3.3 V and hence sources from the Vin supply from the Zumo shield which is 7.5 V

I will be using the arduino for the sole purpose of controlling the motors. All the sensors' data computation will be taken care by the Teensy over the I2C bus. The teensy and entuino communicate with each other via the hardware UARTs, (0, 1) on the entuino and (0,1) Serial1 on the Teensy. The Teensy also has a NRF24L01+ interfaced over the SPI bus for remotely controlling the bot and for data telemetry. The Teensy base board also has support for the ESP8266 wifi (not connected) and a 40 pin header to connect the Raspberry Pi. The Teesny baseboard and the RPi communicate over the UART. The whole block diagram of the entire system is shown below. Currently the ESP8266 and RPi are not connected to the teensy baseboard. Initially i had planned to use the SoftwareSerial library on the teensy for comms between teensy and entuino, but that backfired as the SoftSerial library is defunct. Therefore, i patched the ESP uart to the hardware uart of the entuino (the white wires in pics below).

The fully assembled robot.

The two boards

Now i have to take utmost care to solder the 40 pin header whose component side is behind the board. R.I.P ESP8266. #facepalm, softwareserial #fail.

The Eagle schematic. Not perfect i must say, jeez, look at some vias and those clearances... :P

Fully Powered Up

More adventures with this in Short Circuit - Part 2.

Visible Light Communication Chronicles - Part V - The Boards

The boards are here !! The images shown below are the VLC RX and TX boards i designed as shields for the Arduino UNO. An array of 12 LEDs forms the transmitter, a TEMD6200FX photodiode on the RX board, an Analog Devices XRAD8051 transimpedance amplifier followed by a SY8890 limiting amplifier. The wires on the TX board are test points i added at every stage of the output blocks. The FTDI is an alternative interface to connect the boards on USB-UART to a cellphone over OTG. The control path signalling is implemented using the NRF24L01+ RF module.

Time to solder all them components and get 'em boards runnin' (strong southern accent :P)

Adafruit NeoPixels + Windows Phone 8

This is something that i wanted to do since a long time. Individual control of RGB LEDs on the Adafruit NeoPixel Shield over a bluetooth connection using my Lumia 920 running the Windows Phone 8, After extensively surfing MSDN help articles on WP8 APIs etc - Finally finished it this weekend.

Find the updated design, click here

In brief the design goes like this - An Adafruit NeoPixel shield containing 40 WS2812B 4-pin chip RGB LEDs in a 5 x 8 matrix pattern is mounted on an Adafruit Bluetooth Shield, the EZ Link which is stacked over an Arduino UNO. The code running in the Arduino reads the commands received on the serial bluetooth link, parses it and controls the RGB LEDs. The command packet sent from the Windows Phone consists of 5 fields - two fields for the X and Y co-ordinates of the LED and 3 fields for the R,G and B data obtained from the color picker.

The application on the windows phone is simply a grid of tiles created using the Coding4Fun WP toolkit. Each tile is identified uniquely by its name. Each tile can be set to a different color when clicked and has a one to one mapping with the LEDs on the adafruit shield. The color can be previewed in realtime. Some application statistics and setup are shown in below images. Once the code is well-organized i shall put it up here, and no, i did not write 40 event handlers for each of the tiles. There is only one event handler to rule them all :P

Once powered up the Arduino waits for a command on the BT Serial interface. When the application is started on the windows phone it establishes a connection with the BT module. On clicking any of the square tiles in the main application window another window opens up from where the color for that particular LED can be chosen. Alternatively all the LEDs can be turned off using the Turn Off button. The two wires in the pic below are the RX/TX pins from the BT shield connected to the Arduino over the SoftSerial interface...

P.S - The red color of the tiles is the default theme color on application startup. The LEDs do not get affected by this color unless programmed to

Here is an earlier experiment with a s ingle RGB LED breakout using Processing. The code for this can be found in the description of the video....

Arduino + TFT LCD

I happened to find this 2.8 " TFT LCD on ebay here manufactured by a chinese company called ARMJISHU. The only way i came to know about this TFT was because of the fact that the manufacturers were generous enough to put their website url on the PCB silkscreen. If this detail would not have been there i would never have known what display driver chip it runs or what touchscreen driver it uses. If you head over to the ARMJISHU site it's all in chinese and i could not find this tft sold as a separate product. It was however sold as a part of their STM32 kit. It was in the CD for this kit (which was a whopping 1.2 GB download from the site) that i found the source code for all the peripherals used by the kit and in the tft example i found that the driver was a SSD1289 and a ADS7843 touch controller. 

Once you know the controller it is pretty easy to find the Arduino drivers for the same. I hooked up the tft to the Arduino MEGA and was able to run some sample code using the UTFT library. The touchscreen never worked with this library from elechouse. I am guessing it's damaged. I saw many posts on the internet about people not being able to use this TFT just because they could not find details about it. I hope this post serves as a reference, if they find this post ;)

 The connections for the ATMega 2560. The colored names are the pins on the TFT header. CS is actually named LCD_CS on the tft pcb. RD pin on the tft header has to be directly connected to 3.3V.

The output. Something does not seem right ? Can you guess the last number in the sequence ?

The hookup guide for the TFT using the Mega can be found in the UTFT pdf manual. The code i used is just the example available in the UTFT lib. One has to just uncomment the Arduino Mega API call and comment out the Uno one. The first parameter to the class variable declaration has to be set to the display model, in this case SSD1289.

Update

While using the ADS7843 library from the link mentioned above you might get some errors in ads7843.h like:

ads7843.h:34: error: ISO C++ forbids declaration of 'Pio' with no type

ads7843.h:34: error: expected ';' before '*' token

In order to fix this, open the ads7843.h file and comment out the line as shown below (the second line too

is of no use hence comment that as well)
 

Next, open ads7843.cpp file and disable the code shown below from the class constructor

The compilation should now be successful...

Arduino + WizNet Ethernet Shield + Xively

I got this WizNet Ethernet Shield that i wanted to try out with the Arduino since the CC3000s proved to be a complete disaster. The shield appeared to be of chinese make and quiet different from the original Arduino Ethernet shield. I stacked my Sparkfun Weather shield on top of it as shown below only to find out that there was no provision to connect the I2C lines from the Arduino. SDA and SCL were not brought out onto the ethernet shield. Even the IOREF pin was not connected which was not helping the weather shield as the temperature and humidity sensor were interfaced using I2C and also needed the reference voltage. Looks like i have to tryout the original arduino ethernet shield sometime which has the I2C header present.Anyways i can only acquire the light sensor data using sparkfun shield using the existing setup.

 The code for the same is as below and what i had shown in an earlier post. The temperature and humidity settings have been zeroed out. The data is sent out to the Xively website.

Alternatively to test how effective the ethernet shield was i sent a value of 0 and 50 alternatively every 2 seconds to the Xively website. The code for that is shown below. Also shown below is the screenshot from the Xively site displaying the incoming data in the graph. Ideally the graph is supposed to be a continuous " saw waveform". The gaps that you can see are the connection to the xively site failing. It takes some amount of time to get back online. But it does recover unlike the CC3000 that goes into some infinite loop. So, apart from the fact that the I2C is messed up, i kinda like this shield. I hope the guys who made this shield add those I2C headers.... :)

Technical Index

A collection of all technical articles on this site for quick reference.This page will be bumped up to the top each time i add something new.

• Visible Light Communications.
• ARM FastModels - Part 1 - The Raven SoC
• Digilent Zybo Linux Bringup
• Vibration Robots - Iteration 1 - Chaos
• Ground Surveillance Robot - Short Circuit Part 2
• FreeRTOS on Xilinx Zynq 7000
• Short Circuit - Part 1 
• Samsung S Pen Internals
• Interactive Wireless RGB Light
• Interactive Bluetooth RGB LED 
• Brainf* Interpreter in C
• ARM Assembly: Bubble Sort
• VLC Using a Lumia 920 and Galaxy S5
• The CC3000 Wifi
• Arduino and Internet Of Things
• Arduino Ethernet and Xively 
• Arduino and A TFT LCD
• Teensy - The RESET Pin
• Freetronics OLED and IMU
• Freetronics OLED and Accelerometer
• FreeRTOS on Teensy 3.1
• Ableton Live Controls WS2811 RGB LEDs
• The NRF24L01
• ADXL 345 Breakout Fix
• FreeRTOS on BeagleBoard
• A USB Hack ?

GitHub:
https://github.com/circuitsenses 


Thingiverse:
https://www.thingiverse.com/rishifranklin

Visible Light Communication Chronicles Part III

Welcome to Part 3 of my experiments with visible light communication. In this post i will reveal the final circuit that i used for transmitting UART data over the link. Alternatively i also managed a successful Manchester encoded data transmission over the VLC link. The circuits for the transmitter and receiver are shown below. This is the most basic configuration and yields a maximum UART data transmission rate of 2400 Baud (with flicker) and transmission of Manchester encoded data stream at 1200 Baud (no flicker).

The transmitter above consists of a P55NF06 N-Channel MOSFET whose gate is driven by one of the Arduino pins. The data stream is directly connected to the gate. This causes variations in the drain to source current and varies the drain source voltage Vds and hence the intensity of the LED. This circuit just acts as a modulator. VDD is kept at 13 Volts and in the ON state the LED draws approximately 0.87 A. In the next iteration of this circuit i plan to buffer the gate input and also add a gate driver for a faster response. The code on the transmitter side is hown below. This is the Manchester encoded data stream using the Manchester library for Arduino that you can find here. The test code is pretty basic and just transmits a string of data. As a homework you've got to figure out other parts of the code yourself. No freebies !! Same goes for most circuits.

As mentioned in earlier posts the receiver consists of a TEMT 6000 ambient light sensor whose output is coupled through a capacitor into a LM324N based non-inverting comparator. The reference voltage to the comparator is selectable between 2.5V and 3.3V. This determines how accurately the signal is re-constructed. The output of the OP-AMP is then connected to an Arduino pin as input via a buffer. The various signals are shown below. The power rails of the LM324N quad are connected to 5V and GND.

The output of the TEMT 6000 is in orange. This signal is fed into the OP-AMP non-inverting input. Observe the non-linearity due to the fall time. This is the signal for a Manchester encoded data at 1200 baud. The signal in blue color is the output of the comparator. Based on the reference voltage set the timing of the manchester data stream is not affected and can be decoded easily.

In the above case i reduced the drain-source voltage Vds to around 8V thereby reducing the intensity of light. Observe the non-linearity in both the rise and fall-times of the TEMT 6000 sensor. However the comparator was successfully able to re-construct the signal. The code on the receiver side is shown below

The plots for UART data are shown below. The first plot is the UART data at 2400 Baud with Vds = 13V. The second plot is the same data at 2400 Baud but with Vds = 8V. Note the effects of LED brightness on the output of the sensor. The orange plot is the sensor output and the blue plot is the comparator output. The dark black horizontal line is Vref at 2.5V.

Complete loss of timing information in this one

This concludes the initial stages of experimentation for the visible light communication link that i want to build. The primary objective right now is to find a high speed sensor whose rise and fall times are in the nanosecond range. Less than or equal to 100 ns preferably. Once i get my hands on the new sensor i will post the details about it here. Until then, take it easy.....

Visible Light Communication Chronicles Part II

This is the continuation from Part I on my experiments with visible light communication that i posted sometime ago here. I set up a basic transmitter - receiver circuit, a square wave was given as an input to the transmitter and the output of the reciever was monitored. The transmitter consisted of a N-channel power MOSFET - P55NF06 driving a LED and the receiver consisted of the TEMT 6000 ambient light sensor. The square wave signal was generated using an Arduino MEGA and all the I/O signals were monitored using the Digilent Analog Discovery. Why i chose the above mentioned MOSFET ? because i already had it in stock and decided to use it. The light source is a commercially available 10 W high power LED which i got over here.

Transmitter

The overall circuit is shown below. The gate of the MOSFET is driven by one of the arduino pins. The sketch on the arduino is nothing but the blinky sketch. By adjusting the parameters to the delay function i could generate a square wave from 2 KHz (delay(1)) to 0.5 Hz (delay(1000). The gate resistors Rs and Rg were chosen such thar R1 << R2. From the datasheet, the P55NF06 N-channel mosfet has a drain-source voltage of 60V and a max drain current of 50A.The gate threshold voltage is around 2-4V. The LED forward voltage is around 7V. When turned ON the LED draws approximately 0.5 A which is within the spec of the MOSFET. The transmitter is assembled on a breadboard (yeah kind of not a good choice for a circuit like this, specially considering the mosfet parasitics, you never know...)

Receiver:

The receiver consists of the TEMT 6000 breakout board powered via a 3.3 V supply and it's output fed into the analog discovery. 

The distance between the RXR and TXR is 6 cm. I kept it small for initial measurements. All the signals seen on the scope of the analog discovery are shown below.

The above square wave has a time period of  2 seconds, 0.5 Hz. The blue signal is the input signal and the orange signal has been captured at the output of the ambient light sensor. Note that the rise time and fall time of both the signals appear to be instantaeneous. Also note that when the LED is OFF the TEMT sensor output does not drop to zero but goes to around 48 mV which as i mentioned in an earlier post is the interference from the fluorescent light in my room. The interference is visible in the above image when the input signal is 0V.

The input signal here is of 5 Hz. The output of the ambient light sensor follows the input given to the MOSFET. Note the ripple in the output when input goes to 0V.

In this case the input signal is of 50 Hz. Notice that the output signal starts exhibiting some non-linearity when the MOSFET turns OFF. The interference due to the fluorescent light starts getting negligible. More on this a scroll later.

In this case the input signal has a frequency of 500 Hz. If we continue to increase the frequency the signal at the output of the TEMT 6000 almost disappears and all we get is a DC voltage. with very faint signs of the input signal. After this initial test i decided to give the output of the UART to the TXR circuit and observe the output on the TEMT 6000. Here are the output response of the light sensor to different baud rates

300 Baud.

600 Baud. OFF time non-linearity starts kicking in.

2400 Baud.

4800 Baud. A still noticeable signal that can be recovered using some extra circuitry.

9600 Baud. Beyond 9600 you can only imagine what will happen to the signal at the sensor output.

To investigate on the TXR side. I used a 5V drain-source supply and switched the MOSFET using a 500 Hz gate signal. The following image shows the scope output. The output (orange) was taken at the drain hence the signal inversion. It can be seen that when the gate voltage drops to 0V, turning off the mosfet, the output voltage increases non-linearly with time.(based on the mosfet turn-off delay parameters). The delta is 46.7 usec. The datasheet says that the turn-off delay is around 30 nsec for the specified test conditions.

Allrighty that is a lot of information in this post. Part 3 of this series will elaborate on the analysis of the circuit, MOSFET parameters and the above plots.  Until then, take it easy...

Update

I did one more test in which i plotted the TEMT6000 output over the drain-source voltage Vds.

The orange plot is the output of the light sensor and the blue plot is Vds, which is inverted as i connected the scope to the drain as shown in the schematic. The nonlinearity that i had seen before was therefore confirmed to be due to the TEMTP 6000 sensor. I did a couple of tests with varying input frequencies and found that in all cases the time it took for the sensor outout to go from maximum to 0V was 1.4 msec.which means that it can handle signals from 1 Hz to 714 Hz approximately. This was true as seen in the output plots above. Increasing the Vcc for the sensor to 5V does not help. Time to find a better sendor or fix the output of this one. I will probably have to make a new board and change the 10K resistor to a more feasible value.