Epyon.behttp://www.epyon.be
A blog about technology, science and general awesomenessSat, 12 Jan 2019 23:14:38 +0000en-UShourly1https://wordpress.org/?v=4.9.3Raspberry Pi 3 B+ with KeDei 3.5 inch 480×320 TFT LCD displayhttp://www.epyon.be/2019/01/12/raspberry-pi-3-b-with-kedei-3-5-inch-480x320-tf-lcd-display/
http://www.epyon.be/2019/01/12/raspberry-pi-3-b-with-kedei-3-5-inch-480x320-tf-lcd-display/#respondSat, 12 Jan 2019 20:35:57 +0000http://www.epyon.be/?p=227Up until now my DIY indoor climate logger was based on a Teensy 3.1 microcontroller combined with a 16×2 character monochrome LCD display for basic visualisation of the measurements. After experimenting with Home Assistant, I thought it was time for a more appealing visualisation. I migrated my sensors to a Raspberry Pi, and intended to...

]]>Up until now my DIY indoor climate logger was based on a Teensy 3.1 microcontroller combined with a 16×2 character monochrome LCD display for basic visualisation of the measurements. After experimenting with Home Assistant, I thought it was time for a more appealing visualisation. I migrated my sensors to a Raspberry Pi, and intended to show the measurements on a 3.5″ graphic LCD that would be mounted on top of the Pi.

I specifically wanted a SPI display connected through the GPIO header in stead of a HDMI display that has an awkwardly cable running to the HDMI connector. I knew SPI display support used to be kinda shoddy, but after seeing developments such as fbcp I had some more confidence. I bought a cheap, good looking 3.5″ LCD on Aliexpress, complete with case (pictured) and stylus, assuming Raspbian support for SPI displays would be more or less crystallised by now.

Well, it isn’t.

Turns out the LCD I bought was a KeDei display. These displays are notorious for their bad or often completely missing software support and for changing the type of display controller or even the pinout between iterations of the display, thereby leading to totally different ways of getting the display to work depending on the revision. They do provide their own kernel to make the displays work with Raspberry Pi, but this breaks compatibility with a lot of stuff that otherwise runs just fine on regular Raspbian.

The version I received was v6.3 with date 2018/4/9.

It took me some time to piece together the information required to get this display to work, so I wrote this guide for those who currently find themselves in the same position as me. The hardware used in this guide is a Raspberry Pi 3B+ running the official Raspbian distro with kernel 4.14.34-v7+. It’s possible this guide also works for other hardware and distros, or even other versions of the display, but your mileage may vary.

Login to your Pi through SSH or start a command line shell from the GUI. It can never hurt to first update your Pi, so everything is the latest version.sudo apt-get update
sudo apt-get upgrade

When this is done, browse to your home location and download the driver from the manufacturer.cd Downloads
wget http://en.kedei.net/raspberry/v6_1/LCD_show_v6_1_3.tar.gz

When the tarball has been downloaded, lets unpack it and browse to the newly created directory.tar -xvzf LCD_show_v6_1_3.tar.gz
cd LCD_show_v6_1_3

Now run the install script, and wait a very long time.sudo ./LCD35_v

The Pi will reboot in the process, but everything will take several minutes. Go grab a coffee and let everything run its course. Your LCD should display the Raspberry Pi berries once the Pi has rebooted. Log back in to the Pi.

To make the LCD work, we need to activate the OpenGL support on the Pi. Run the Raspi config tool withsudo raspi-config

Now for the finishing touches, we need to edit config.txt. This is sort of the BIOS of the Pi, where it stores configuration information that is read during boot. Navigate to the boot directory and open the file.cd /boot
sudo nano config.txt

(Note that rather strangely you need to disable SPI to make the SPI display work.)

Finally, add or change the following lines at the end of the file.hdmi_force_hotplug=1
gpu_mem=32
start_x=0
enable_uart=1
dtoverlay=w1-gpio

Press ctrl-x and save under the same name.

Now reboot the Pi one last time
sudo reboot

Rejoice! After the Pi has booted the Pi’s desktop should now be displayed on the LCD. The touchscreen should be working too now.

Note that you can’t use the SPI display and HDMI output at the same time, unless you use some kind of framebuffer copy. If you want to use the HDMI output again, start a shell into your Pi and run the LCD_hdmi scriptcd Downloads
cd LCD_show_v6_1_3
sudo ./LCD_hdmi

]]>http://www.epyon.be/2019/01/12/raspberry-pi-3-b-with-kedei-3-5-inch-480x320-tf-lcd-display/feed/0Designing a solar powered TTN gatewayhttp://www.epyon.be/2017/02/23/designing-solar-powered-ttn-gateway/
http://www.epyon.be/2017/02/23/designing-solar-powered-ttn-gateway/#respondWed, 22 Feb 2017 22:42:49 +0000http://www.epyon.be/?p=173In a couple of threads on the TTN forum, some questions on the power consumption of a LoraWAN/TTN gateway have been raised, and whether it could be powered independently, e.g. through a solar panel. I decided to revisit this topic while working on a guide on lightning protection for gateways. Completely isolating your gateway from...

]]>In a couple of threads on the TTN forum, some questions on the power consumption of a LoraWAN/TTN gateway have been raised, and whether it could be powered independently, e.g. through a solar panel. I decided to revisit this topic while working on a guide on lightning protection for gateways. Completely isolating your gateway from the building it is on is an effective way to provide lightning protection. It also opens up some possibilities for ‘guerilla gateways’ which you can place anywhere without being tied to the availability of power.

Obtaining data

I have access to detailed AC and DC yield data from a 4.8kW solar array oriented perfectly south under a 40° vertical angle, providing very valuable reference data. I used the worst case DC yield data, namely the dark months November, December and January. We had the ‘luck’ to have some extremely clouded weeks these months, so a setup that can bridge these periods will certainly survive the rest of the year.

Having access to PV yield is one thing, but an accurate prediction of the power consumption is another. I decided to hook up my Raspberry Pi powered ic880 gateway to our venerable Voltech PM3000 power analyser and let the integrator run for a couple of days. I measured the power consumption the Raspberry drew through its USB port. The gateway was operating normally, that is mostly receiving data from nodes. Except for the occasional transmission from other users, I did not specifically perform transmissions. The gateway was connected to the internet through Ethernet.

On average, the gateway drew 3.2 Watts of power on the 5V DC USB line (figure 1).

This was confirmed by the integrator, e.g. after 25.66h it had consumed 82.76Wh of energy averaging 3.23 Watts of instantaneous power (figure 2).

Figure 2: consumed energy after 25h

System model

With these figures in hand, it was time to build a (simplified) system model. I defined a classic DC-coupled off-grid model as depicted in figure 3. It consists of a solar panel, a solar charger/controller, a lead acid battery, a DC/DC power supply and, of course, the gateway.

Figure 3: solar powered TTN gateway system model

I’ll talk some more about each component, you can scroll down to the results if it doesn’t interest you.

Solar charger/controller

The solar charger/controller has some specific parameters to take into account, namely the quiescent current Iq (self-consumption) and the power conversion efficiency η.

As you can see in figure 3 I went for a MPPT solar charger/controller instead of the cheaper and more ubiquitous PWM controllers. PWM controllers are a great choice if the voltage of your solar panel more or less matches the voltage of your storage medium and if you principally expect sunny (hot) operating conditions. The required size of our solar panel was however (spoiler alert!) too large to be practical with 12V panels matched to our lead acid battery, and we are especially concerned with performance during the cold winter months. I therefore went for the more efficient MPPT controller. These controllers frequently offer more advanced battery charging strategies, e.g. desulfation, and a dedicated load connection optimising battery capacity and battery life.

MPPT controllers do cost a bit more and have somewhat higher quiescent current than MPPT controllers, but have overall higher efficiency. I based the controller in my model on the Steca Solarix MPPT with an average efficiency of 95% and a quiescent current of 10mA. I’ve had good experiences with Steca in the past so it’s kinda my go to brand when looking for solar chargers. MPPT will generally be around 80-85% efficiency.

Energy storage medium

As in most off-grid applications the selected energy storage medium is a lead-acid (LA) battery. LA offers superior cost/capacity ratios compared to other battery types at the cost of size and weight. This is however a stationary application and the size of the battery will be much smaller than that of the PV panel, so we don’t have to worry about these parameters.

Not all LA batteries are born equal though. I selected the Vision Akkus 6FM75T AGM type storage battery. In this type of battery the electrolyte is Absorbed in a Glassfiber Mat (hence AGM). These batteries are maintenance free, can be mounted in non-horizontal positions and can cope better with cold temperatures. Most importantly however, they last many charge/discharge cycles (up to 1.600 and more), can handle partial discharge and have limited self-discharge (around 3% per month). They are built to supply a steady current flow to the load. We assumed an overall 85% charge/discharge efficiency, taken into account (spoilers again) the very high average SoC of around 83%.

Don’t use a flooded LA battery, commonly known as a car battery. Car batteries are built to supply a short burst of incredibly high current and expect to be fully recharged regularly, and make for very poor long term energy storage mediums.

DC/DC converter

The Raspberry Pi powered gateway operates on 5V, so I used a DC/DC converter to step down the 12V battery voltage to 5V. The gateway draws on average 670mA, so a power supply rated 1.2A or more should be sufficient. Best to buy a premium brand to ensure a stable output. We went for an overall 85% conversion efficiency, loosely based on the XP Power DTE40.

System model

The calculation model is a simplified model based on the assumptions above. Solar energy from the PV panels is first converted to a steady 12V power taking the solar charger efficiency into account.

The gateway draws a steady 3.2W at 5V. I’ve raised this figure by 20% to 3.8W to be sure. On the 12V side the DC/DC converter efficiency is likewise taken into account resulting in around 4.4W power draw. The quiescent power draw of 0.12W from the MPPT controller is added resulting in a total power draw of around 4.6W.

If the energy output of the solar charge controller exceeds the total power draw, the excess power is stored in the battery at an efficiency of 85%. If the total energy draw exceeds the solar charger output, power is drawn from the battery. This is a further simplification because the real charge/discharge efficiency is dependent on the SoC. However the model resulted in a very high average SoC, making the average of 85% acceptable.

Results

The model has two variable inputs: solar panel size and battery storage capacity. The goal is to incur zero downtime and to never reach a battery State of Charge (SoC) lower than 30%, which is the under-voltage cutoff for a LA battery.

I varied both inputs and plotted the combinations resulting in a minimal SoC of 30% or more. This resulted in figure 4.

As one can see, the extreme values are a minimal solar panel size of 100W and a minimal battery storage size of 40Ah. Everything below that results in an insane value of the other parameter.

In figure 5 the battery SoC (blue) and solar energy yield (red) are plotted for a solar panel size of 150Wp and a battery capacity of 75Ah. As one can see, this setup is able to bridge around 6 clouded days without dropping below a 30% SoC, resulting in zero downtime. In general I would recommend a somewhat bigger solar panel size, say 180Wp to 200Wp.

Figure 5: solar panel energy output and battery state of charge during November-January for solar panel size of 150Wp and battery capacity of 75Ah

Is it worth it?

A setup as described above would cost something like this

Item

Cost

200Wp solar panel

€120

Steca Solarix MPPT 2010

€210

Vision Akkus 6FM75TX 75Ah battery

€199

DC/DC converter 12V-5V

€30

Grand total

€599

Take some €40-ish into account for mounting and cabling and you end up around €600 for this self-sufficient gateway. That is without the cost for the gateway and the antenna, mind you.

So is a completely off-grid, self-sufficient gateway doable? Totally. Is it worth the price? That’s for you to decide.

]]>http://www.epyon.be/2017/02/23/designing-solar-powered-ttn-gateway/feed/0Test of a cheap Chinese Wiz850io Ethernet boardhttp://www.epyon.be/2016/12/06/test-cheap-chinese-wiz850io-ethernet-board/
http://www.epyon.be/2016/12/06/test-cheap-chinese-wiz850io-ethernet-board/#respondTue, 06 Dec 2016 20:31:23 +0000http://www.epyon.be/?p=151The Wiznet chips are arguably the easiest and most straightforward way to get a Teensy, or just about any Arduino compatible development board, on the internet. Ever since the W5100 in the first Arduino Ethernet shield, these chips have been the weapon of choice for most tinkerers. The small-footprint, Wiznet-provided Wiz820io, based on the W5200,...

]]>The Wiznet chips are arguably the easiest and most straightforward way to get a Teensy, or just about any Arduino compatible development board, on the internet. Ever since the W5100 in the first Arduino Ethernet shield, these chips have been the weapon of choice for most tinkerers. The small-footprint, Wiznet-provided Wiz820io, based on the W5200, proved to be an excellent match for the Teensy, with a handy adapter board by PJRC to go in between.

The only downside to the Wiznet chips was their price. A Wiz820io would easily go around €24/$26 online, a price point where you could easily get 6 or more ENC28J60 Ethernet boards for on Ebay. Okay, the ENC doesn’t have the stability of the Wiznet stack (I have W5200 boards running for years now without even a single hiccup), but hey, it’s only €3! I drink beers that cost more!

Recently, very cheap Wiz850io boards are appearing on sites such as Ebay and Aliexpress. The Wiz550io boards are built around the W5500 chip, which is an optimised version of the W5200, which in turn is a huge improvement of the venerable W5100. The W5500 has pretty much the same specs as the W5200, but consumes less power and is cheaper, presumably because of higher yields. The Wiz850io is pin-compatible with the popular Wiz820io. While Wiznet-made Wiz850io boards sell around €14/$15, the Aliexpress ones go for €8 and less. These seem to be ‘China Export’ versions of the Wiznet reference design, but with the genuine W5500 produced by Korean Wiznet.

I bought some of these Wiz850io’s to check if they we’re the real deal. Oddly, these boards we’re called ‘Wiz850io W5500 ENC280J60 Ethernet Chip’. And now they’re just called ‘W5500 Chip SPI’. Searching for Wiz850io on Aliexpress even yields no results anymore. Seems like Wiznet cracked down on the use of their Wiz850io product name. Even though they changed names, the products seem to be the same however.

The familiar sight of the white envelope with Chinese letters marked ‘gift’

I paid €8 per board, including shipping – which took exactly two weeks. The boards arrived decently packaged in anti-static bags. The form factor was identical to the Wiz820io’s I used until now, as should be. The UDE magnetic-integrated socket was replaced with a HanRun one, reminiscent of ENC28J60 boards. The headers had an unusual yellow color. There was also a red LED below the RJ45 socket.

The Chinese Wiz850io left, the official Wiz820io right

Seems like an original Wiznet W5500 chip

Since Teensyduino 1.32, released for Arduino 1.6.13, the W5500 is fully supported in the Ethernet library. I used the Chinese Wiz850io on the PJRC adaptor board connected to a 100Mbit switch and ran a sketch that assigned an IP through DHCP and then requested HTML pages from the internet, before doing the same test on a regular Wiz820io. Meanwhile I measured the current consumption on the 5V line.

The Wiz820io on a Teensy 3.2 using 218,7mA @5V

The Wiz850io on a Teensy 3.2 using 160,1mA @5V

5V power consumption of a Teensy 3.2 with the Wiznet 850io vs 820io Ethernet board

Wiz850io

Wiz820io

Requesting HTTP

160mA

218mA

No cable connected

100mA

174mA

Teensy only

37mA

37mA

Both the regular Wiz820io and the Chinese Wiz850io performed perfect, with DHCP IPs being leased and webpages requested without a problem. The continuous power consumption of the Wiz850io was around 26% less than the Wiz820io, and was even lower than the no-cable-connected power consumption of the latter. With around 128mA being used, this seems consistent with the power consumption of the official Wiz850io as provided by Wiznet.

I haven’t done long term stability testing, but so far it seems like these cheap Wiz850io clones are China made versions of the official reference design and are working equally as fine, but saving you a buck or 7.

]]>http://www.epyon.be/2016/12/06/test-cheap-chinese-wiz850io-ethernet-board/feed/0Non-blocking ethernet example for Teensyhttp://www.epyon.be/2016/05/22/non-blocking-ethernet-example-teensy/
http://www.epyon.be/2016/05/22/non-blocking-ethernet-example-teensy/#respondSun, 22 May 2016 14:33:37 +0000http://www.epyon.be/?p=129To me one of the biggest nuisances with Arduino is the blocking behavior of their standard Ethernet library. I use Ethernet a lot in my projects, not to say constantly, and with the default library my application would just be sitting there doing nothing while the Ethernet connection is being set up. This can even...

]]>To me one of the biggest nuisances with Arduino is the blocking behavior of their standard Ethernet library. I use Ethernet a lot in my projects, not to say constantly, and with the default library my application would just be sitting there doing nothing while the Ethernet connection is being set up. This can even take up to a full minute (standard time-out) if no DHCP lease can be obtained.

A pull request from 2013 extended the default library with a non-blocking method. Not-so-surprisingly this was not committed into the official release. Guess the Arduino team was too busy developing bloated products that fill up the inventories of Sparkfun and the likes.

I moved away from AVR hardware quite some time ago and nowadays the Teensy is my development platform of choice. Teensy user Headroom modified said non-blocking library to work with this platform. However, DNS resolving did not work for me. I dug into the library to find the cause and implemented a small workaround. Adding a small delay in the DNS processing function seemed to fix it (line #273 in Dns.cpp). I am by no means a seasoned programmer, so I will leave finding the root cause of the problem to someone else.

The exact use of the library was not readily apparent. It took some time figuring out how to use it, because between the initially provided example and Headrooms modification some functions changed name.

Below I provide an example sketch to show you how to use it. I also incorporated macadress.h discussed here, which automatically uses the Teensys built-in MAC address for setting up the Ethernet connection. It is tested with Arduino 1.6.8, Teensyduino 1-28b, Teensy 3.1 and 3.2 and the Wiz820io Ethernet shield. It should work with any W5100/5200 based shield.

The library launches a DHCP request to the router and periodically checks to see if a lease has been obtained or is still valid. Meanwhile your sketch can do other stuff. Just keep on calling doEthernet() in your main loop(). The example sketch launches a DNS resolve request (also non-blocking) once a valid lease has been obtained and then makes a HTTP GET request to the server.

]]>http://www.epyon.be/2016/05/22/non-blocking-ethernet-example-teensy/feed/0Teensy-Arduino Crossover (TAX) Shieldhttp://www.epyon.be/2014/05/04/teensy-arduino-crossover-tax-shield/
http://www.epyon.be/2014/05/04/teensy-arduino-crossover-tax-shield/#commentsSun, 04 May 2014 21:22:57 +0000http://www.epyon.be/?p=92Note: if you just want the technical specifications of the board, see this page. I can’t believe it’s already been over ten months since my previous update. Time does fly when you’re combining two jobs with an as normal as possible social life, apparently. Since my previous posts, a lot of people in the comments,...

]]>Note: if you just want the technical specifications of the board, see this page.

I can’t believe it’s already been over ten months since my previous update. Time does fly when you’re combining two jobs with an as normal as possible social life, apparently.

Since my previous posts, a lot of people in the comments, mails and on the PJRC support forums have asked me when the Teensy adapter board will be out, if ever. Truth is, the hardware was as good as finished and ready for production if it wasn’t for the bidirectional level shifters. I placed these on the board to perform bidirectional level shifting between the 3.3V Teensy and 5V Arduino shields.

Out with the old

Unfortunately, the TXB0108PWR level shifters aren’t functioning as straightforward as the datasheet wants you to believe. When not all the pins on one side are on the same potential, the pins on the other side start acting strange. Pins that should be at a low logic level float around 3V, the edges of the output signal are skewed, there’s signal noise etc.

After ensuring this odd behavior wasn’t due to my PCB design (by testing the TXB0108PWR ICs directly), I had a lengthy discussion about it with some TI engineers. It didn’t lead to a workable solution. You can’t expect all the pins on one side to be on the same potential, because Teensy users will want to mix and match input and output functions. So I was left looking for an alternative solution, but my other occupations (like writing a PhD and running a small software company), soaked up all my available time.

Then some time ago, Paul from PJRC released the Teensy 3.1 using the MK20DX256 chip instead of the MK20DX128. This chip brings, together with some other nice features such as simultaneously sampled ADC’s and more memory, 5V level tolerance to the table (or should I say: board). This kinda rendered the use of level shifters void. You can directly apply 5V outputs without damaging the chip, and you can drive 5V TTL inputs with the 3.3V output of the chip.

In with the new

My first idea then was to make a revision to the board removing the level shifters, but maintaining other functionality such as the analog scaling. Bringing such a board into production wouldn’t be feasible economically however. In small quantities the board would have to sell around €20 to cover all expenses, so it would cost more than the Teensy 3.1 does!

My second idea then was to just integrate the Teensy into the board. The biggest production cost is actually the PCB and not the components. By putting the MK20DX256 and the Mini54 bootloader chip onboard, the board would gain a lot of functionality without increasing the cost much. I decided to pursue this idea further, and nicknamed it the TAX board: Teensy Arduino crossover (X) board.

TAX does pretty much the same as the previous board, but now without having to solder a Teensy on to it. The digital inputs are 5V tolerant thanks to the MK20DX256 chip. The analog inputs have the same 5V/3.3V voltage divider and retain the buffering opamp resulting in good signal quality and improved speed over regular voltage dividers.

A bonus is the onboard 3.3V voltage regulator, providing a clean supply voltage instead of the sometimes noisy voltage rail on the Teensy board. It also has a higher power output of 750mA. For programming, a USB type B receptacle is used instead of the micro-USB found on the Teensy, giving the board the looks of an Arduino Uno. Some people were complaining about the micro-USB receptacle wearing out pretty fast, but the type B is more robust. Plus you can use all of your Arduino cables!

Some extra pins of the MK20DX256, like the DAC, are tied to an extra header (placed where you would normally find the ISCP header for the USB to serial converter on an Arduino Uno). The dedicated serial header, compatible with the most FTDI boards floating around the web, is present again. You can also power the board through this header.

Talking about power, TAX has an automatic power selector circuit. You can now safely power it by supplying 5V through a header, using a 6-16V power supply connected on the DC barrel connector or by connecting a USB cable. The selector circuit will automatically select one power supply if more than one is connected.

So in short: TAX is a Teensy 3.1 compatible board in the Arduino form factor. You can use it with pretty much all existing Arduino shields and program it through the Arduino IDE (provided you have the Teensy add-on installed). It’s just like an ordinary Arduino Uno, but now with the power of the MK20 chip (72MHz, 264kB flash, 65kB RAM etc.)

Status

I have build a number (four, to be exactly) of prototype boards to test functionality. After a few weeks of testing, everything seems to be in order. The boards behave just like an ordinary Teensy or Arduino would, so that’s good.

Currently (may 2014), a new batch of prototype boards is at the PCB fab. I did some minor routing and pin changes of which I want to be sure it works flawlessly. I expect to have the testing done in a week or four.

Response to my previous adapter shield has been great, so I hope this new version will be able to captivate the same enthusiasm. I think the potential is big enough to put it in limited production, so be sure to check in on this blog for further updates! Also, please leave your comments and feedback in to the comments section. It’s important to know what you guys think and where I could improve the design.

]]>http://www.epyon.be/2014/05/04/teensy-arduino-crossover-tax-shield/feed/14Teensy-Arduino adapter shieldhttp://www.epyon.be/2013/07/18/teensy-arduino-adapter-shield/
http://www.epyon.be/2013/07/18/teensy-arduino-adapter-shield/#commentsThu, 18 Jul 2013 20:55:57 +0000http://www.epyon.be/?p=41Ever since I discovered the Teensy 3.0 board from PJRC, I’m hooked up to it. It’s compatible with the Arduino programming language, but the microcontroller is so much more powerful than a regular Arduino or even the Arduino Due. The only downside is the limited amount of Teensy expansion shields. But what if you could...

]]>Ever since I discovered the Teensy 3.0 board from PJRC, I’m hooked up to it. It’s compatible with the Arduino programming language, but the microcontroller is so much more powerful than a regular Arduino or even the Arduino Due. The only downside is the limited amount of Teensy expansion shields. But what if you could hook up all your Arduino shields to the Teensy? You could then take advantage of both the powerful microcontroller as well as the variety of Arduino expansion shields. That’s why I developed the Teensy-Arduino adapter shield, which does just what it says on the tin: seamless compatibility between the Teensy 3.0 board and Arduino shields.

Main features:

Drop-in, pin-to-pin Arduino Rev3 compatible

Convert between Teensy and Arduino footprints: unlock the wealth of different Arduino shields for your Teensy projects

Interface Arduino 5V levels (logic and even analog!) to Teensy 3.3V level: no need to make any change to your existing Arduino projects

Bidirectional logic buffers can source up to 50mA per digital output (up from 9mA per Teensy output)

Select 3.3V logic levels with a simple switch to use your Teensy with 3.3V Arduino shields (in stead of 5V)

A Teensy 3.0 board mounted on the Teensy-Arduino adapter shield

Status of the shield

Currently, I’m testing prototype versions of the shield, and I’ll be making some tweaks in order to enhance quality and usability. (e.g. offsetting the Teensy placement a bit more so the USB microconnector isn’t obstructed by the Arduino ICSP header). If you have any suggestions regarding the layout or features of the adapter shield, be sure to leave them in the comments.

I don’t yet know if I’ll put the board in volume production and up for sale or keep it as an internal product in our organization. This because it’s hard for me to estimate if there’s a real demand for this board. If you’re interested in this board, leave a reply in the comments or register your interest with the form below (your email will only be used to notify you if the board has gone into volume production). If I reach 50 interested people, I’ll let the fab churn the boards out.

Oh, the price you ask? Hard to tell, but I expect it to be somewhere around €20 to €30. A bargain considering you unlock the wealth of Arduino shields for your Teensy, right?

Email

Why the Teensy-Arduino adapter shield?

I love Arduino. I really do. I use it almost all the time, at home or at work. Not only is it fun and easy to program with, there’s also an abundance of different expansion shields available.

My only beef with the AVR based Arduino’s is its limited processing and memory capacity. Although the AVR 8-bit microcontroller architecture has aged gracefully, it just isn’t suitable for today’s networked, data-intensive processing tasks anymore. Sure, Arduino now has the 32-bit Due, but at a ridicioulus large footprint and a tad too pricey. And worst of all: they neglected to take advantage of the built-in peripherals provided by the SAM3X chip. No Ethernet wiring, no DMA wiring. Booh!

Then I discovered the Teensy 3.0. A capable, cheap and small 32-bit ARM board. It offers advanced capabilities such as complex math processing. And it’s programmable with the Arduino IDE and language we all love so much! Unfortunately, the smaller footprint and different voltage levels meant I could throw away my amassed army of Arduino shields.

Or did I?

I wanted a board which would allow me to use all my existing Arduino shields without a second thought. I also wanted it to fix some of the ‘prototype-unfriendly’ features 32-bit micrcontrollers have compared to their robust 8-bit brethrens, such as low current sinking/sourcing capability and extreme sensitivity to reverse polarity or too high voltage levels. Hey, we all make some bad wiring decisions in our lifes, don’t we?

Since I design and manufacture a lot of PCB’s at work, I decided to build this adapter board. It interfaces the Teensy 3.0 board with Arduino shields. It takes care of all the logic level translations, increases the drive capability of the digital pins, offers pin input protection, improves the ADC performance and even has it’s own built-in power supply so you can run the Teensy stand-alone. Just for fun, I also added a 12mm coin cell battery holder. It allows you to use the built-in RTC of the Teensy to keep the time, even without power.

But the main thing, of course, is the Arduino compatible footprint. Just place any Arduino shield on top of this board and use it like you would use with an Arduino board, but now with the power of the Teensy 3.0 under the hood.

An Arduino Ethernet shield mounted on the Teensy-Arduino adapter shield

The Teensy-Arduino adapter shield has two TXB0108PWR autosensing bidirectional level shifters taking care of the voltage level translations on the digital pins, including the SPI pins through the ICSP header (e.g. for use with the Arduino Ethernet shield).

Internally, the level shifters work with a single MOSFET transistor, using a clever trick first described by Herman Schutte when he worked at Philips Semiconductor (now NXP). Read the original application note.

As an extra, the level shifters act as a buffer, protecting the sensitive Teensy pins and improving the current sinking/sourcing capability.

The Teensy-Arduino adapter shield also has a VREF switch. This switch controls the output level of the level shifters. Leave it at 5V for use with most Arduino shields. However, when using 3.3V Arduino shields, move the switch to the 3.3V position. The level shifters will now work on a 3.3V level, and the IOREF pin will be now be at 3.3V. This of course degrades the level shifters to expensive 1:1 buffers, but maximizes compatibility with existing Arduino shields.

Note: keep in mind the level shifters will now be supplied 3.3V through the Teensy voltage regulator, so keep total current sourcing within 100mA!

Currently, the Teensy-Arduino adapter shield also has a communication header compatible with the popular Sparkfun FTDI breakout board. This is mainly for my own convenience, because I use a lot of UART communications in my projects and this way I can easily connect the FTDI converter to my Teensy.

Analog

5V compatibility on analog inputs

Increased accuracy, stability and speed of ADC readings

Analog input protection

The Teensy-Arduino adapter shield uses a simple 18k/33k resistor divider to rescale 5V analog inputs to 3.24V (the closest you can get to 3.3V by using standard resistor values). The resistor divider has an accuracy of 1%.

To remove any input impedance mismatch between the resistor divider and the analog inputs, an LM358D opamp in unity gain mode is placed between the resistor divider and the analog input pin. Since this opamp has virtually no output impedance, it instantely charges the ADC input capacitor, (theoretically) removing the need to average multiple ADC readings.

The same resistor divider is also connected to the AREF input of the Teensy. By adding

analogReference(EXTERNAL);

in your sketch, you set the upper limit of the ADC to the maximum value the analog input can ever read through the resistor divider. When you apply 5V to the analog input, the Teensy will read 1023 (in 10-bit resolution), just like it would on a regular Arduino. You can desolder solder jumper SJ1 on the back of the board if you wish to use another external reference.

Note: because of the opamps, the analog inputs of the Teensy can no longer be used as digital outputs. This can be a problem when you use some (older) Arduino shields utilizing I²C communication on analog pins 4 & 5. If you want to use these shields, connect solder jumpers SJ7 and SJ8 on the back of the board. This will connect the I²C pins directly to analog pins 4 & 5, but render the analog input function on those pins void.
Newer Arduino shields use I²C communication on digital pins 16 & 17, and so should you!

Power

On-board 5V power supply

Automatic power supply selection (on-board 5V, USB 5V)

Use the Teensy stand-alone (without USB connection)

3V back-up battery

The Teensy-Arduino adapter shield uses the same LD1117S50 linear regulator found on many Arduino boards and shields, providing clean 5V power from a DC input of 7-15V. The regulator can provide up to 750mA of current, which is more than enough to power the Teensy and a bunch of Arduino shields. The power supply is protected against reverse polarity, just in case.

All 5V logic is supplied through this regulator, unless no external power is connected at which instance it will be supplied through the 5V USB VCC. An opamp/MOSFET combo provides automatic power supply selection. When present, the Teensy-Arduino adapter shield will always run from an external power supply, even when a USB cable is connected to the Teensy.

To avoid circulating currents between the external power supply and the USB port, you should

never connect an external power supply when the Teensy is connected to a USB port

Not respecting these rules may damage your Teensy and potentially open the Seven Gates of Hell. Don’t tell us we didn’t warn you!

As an extra, the Teensy-Arduino adapter shield has a 12mm coin cell holder for 3V LR221 batteries. The battery is connected to the VBAT pin of the Teensy and can be used as a backup power source to keep the internal Real Time Clock going.
Don’tuse it as a backup power source to power your Teensy board, because holy priceless collection of Etruscan snoods, Batman, you would drain the battery in minutes!

Reset

Reset the Teensy board through a pushbutton

Compatible with reset buttons on Arduino shields

The Teensy-Arduino adapter shield has a reset button, which can pull the Teensy reset pin low through a CAT811 voltage supervisor controller. This button is connected to the RESET pin, meaning pushing the button or pulling the RESET pin to ground initiates a reset of the Teensy. The reset button on Arduino shields will provide the same functionality. This can come in handy, e.g. when resetting an Ethernet shield (pushing the reset on an Ethernet shield will simulteaneously reset the Teensy and the Ethernet chip). The CAT811 controller will also initiate a reset when the input voltage drops below 2.6V, preventing undefined states of the Teensy microcontroller.

Note: the reset button does NOT have the same functionality as the button on your Teensy board. The button on the Teensy board is used to bring the Teensy microntroller into programming mode, not to reset it.

Footprint

Arduino Rev3 compatible

Two mounting positions for the Teensy board

The Teensy-Arduino adapter shield uses the Arduino Rev3 layout, meaning it has a IOREF pin signaling the I/O voltage level and digital pins 17 & 18 dedicated for I²C communication.
The Teensy board can be mounted in two ways: on top or below the shield.
On top has the benefit of retaining a flat, stable underside of the board and providing easy access to the Teensy programming button. Below has the benefits of exposing the additional Teensy I/O SMD pads for further expansion.

]]>http://www.epyon.be/2013/07/18/teensy-arduino-adapter-shield/feed/37Using the Teensy 3.0 with the Arduino Ethernet shieldhttp://www.epyon.be/2013/07/06/using-the-teensy-3-0-with-the-arduino-ethernet-shield/
http://www.epyon.be/2013/07/06/using-the-teensy-3-0-with-the-arduino-ethernet-shield/#commentsSat, 06 Jul 2013 20:37:56 +0000http://www.epyon.be/?p=14Do you have a Teensy 3.0 and want to hook it up to the internet? Don’t really feel like breadboarding your own Ethernet interface? Then why don’t you use one of your Arduino Ethernet shields lying around the place to provide the Teensy with Ethernet capabilities? Here we show how to do just that. So...

]]>Do you have a Teensy 3.0 and want to hook it up to the internet? Don’t really feel like breadboarding your own Ethernet interface? Then why don’t you use one of your Arduino Ethernet shields lying around the place to provide the Teensy with Ethernet capabilities? Here we show how to do just that.

So I ordered and received my Teensy 3.0 the other day. However, since I’m a Internet kinda of guy, a microcontroller is only useful to me when I can connect it to a network. The Teensy store sells some adapters to connect a WIZ812MJ Ethernet Module to your Teensy, but they’re meant for older Teensy 2.0 models. Also, I didn’t have one of those WIZ812MJ modules lying around.

Luckily our labs are stacked with Arduino boards, and we did have some spare Arduino Ethernet Rev3 shields. Both the WIZ812MJ Ethernet Module and the Arduino Ethernet shield use the Wiznet W5100 embedded TCP/IP chip, so it’s perfectely possible to use the Arduino Ethernet shield to bring the wonderous world of the Internet to the Teensy 3.0! As an extra, the Arduino Ethernet shield provides a micro-SD slot which you can also use with the Teensy. Both the Wiznet chip and the SD slot work on the same SPI bus, limiting the amount of wires you have to run between the Teensy and the Ethernet shield.

However, there’s always a catch. You need to be sure you have a Rev. 3 Ethernet shield, which is the current model sold by Arduino and their distributors. An older version of the Ethernet shield might damage or destroy your precious Teensy board. Read on to find out why.

SPI is a medium-speed, four-wire digital interface bus. It actually only uses three wires for the bus itself (two data lines and one clock line), and one extra wire to select the device, connected to the bus, the microcontroller wants to talk to. This is the so called Slave Select wire. In our case, we will need two SS wires, one for the Ethernet chip and one for the micro SD-card.

Arduino name

Teensy name

Teensy pin

MISO

DIN

12

MOSI

DOUT

11

SCLK

LED

13

SS

CS

10-9

The SPI bus on the Arduino Ethernet shield is broken out on the ICSP header on the backside of the board. The SS lines are on the regular digital pin headers.
The Teensy 3.0 uses a different naming scheme for the SPI bus.

Now before we go connecting the Arduino Ethernet shield to our Teensy 3.0, a note on why we need the Rev. 3 model of the Ethernet shield. The Teensy 3.0 works with 3.3V levels, while most of the Arduinos use the 5V level. The inputs of the Teensy, or rather the Freescale MK20 microcontroller on the Teensy board, however are NOT 3.3V tolerant. Connecting 5V to them will damage the microcontroller.
The Rev. 3 of the Arduino Ethernet shield features a IOREF pin. This pin is used to sense the voltage level the Arduino operates with and level shift the output of the shield to a compatible voltage. So the Rev. 3 version of the shield can be safely coupled to the Teensy without you having to worry about magic smoke leaving the Teensy microcontroller.

Some remarks about the power supply. The Wiznet W5100 chip works on 3.3V, but it’s quite a power hungry fellow. It consumes up to 150mA, which is around the maximum current the MK20 microcontroller on the Teensy can provide. The Arduino Ethernet shield luckily has a linear regulator converting power from the 5V pin to 3.3V. To avoid damaging the Teensy microcontroller, you should connect the 5V pin of the Arduino Ethernet shield to the Vin pin of the Teensy, provided you use the USB connection to power the Teensy. This way, the Arduino Ethernet shield will use the 5V provided by USB to power the W5100 chip, avoiding putting too much stress on the Teensy microcontroller.