The code supporting USB Mass Storage Class of devices has been added to USB Host Shield 2.0 library and is available to download on GitHub. Mass storage devices include USB Flash drives, memory card readers, external hard drives/CD-ROMs, smartphones/tablets, and some others – almost anything that shows as a drive while connected [...]]]>

Mass Storage

The code supporting USB Mass Storage Class of devices has been added to USB Host Shield 2.0 library and is available to download on GitHub. Mass storage devices include USB Flash drives, memory card readers, external hard drives/CD-ROMs, smartphones/tablets, and some others – almost anything that shows as a drive while connected to a PC (exceptions are digital cameras as well as some phones pretending to be digital cameras). Andrew Kroll (who made this release possible) – thank you very much!

At present, the code example, also featuring Andrew’s FAT and extended memory implementation, can only be run on “big” Arduinos such as Mega and Mega 2560. Another FAT implementation, developed by Alex Glushchenko, is being tested – there is a slight possibility that at least some functionality can be demonstrated on a regular UNO board. On the other hand, the mass storage component can be used without a file system by simply reading/writing physical sectors; this approach can save a lot of memory. The documentation for the mass storage class code is available here.

Many hours has been spent testing the code; it should work with any device which claims to support “mass storage bulk only” transport. While newer (less than 5 years old) won’t cause any problems, older ones could be finicky. If your device shows odd behaviour with this code, please let me know – I will trade it for the good working one.

Enjoy!

Oleg.

CO2 Soldering

Some time ago I noticed that I’m spending more time building boards and less time developing and needed to increase my manufacturing capabilities. After thorough reading Dangerous Prototypes’ Chinese desktop pick and place machine forum thread I got in contact with a factory and bought TM240A – the big [...]]]>

TM240A building USB Host Shields

Some time ago I noticed that I’m spending more time building boards and less time developing and needed to increase my manufacturing capabilities. After thorough reading Dangerous Prototypes’ Chinese desktop pick and place machine forum thread I got in contact with a factory and bought TM240A – the big brother of TM220A. Earlier this week a DHL van carrying 70kg crate pulled in my driveway. After a day of hands-on learning I started building boards. This article was written after 2 days of using the machine and contains my first impressions as well as a couple of hints.

First, it is a real Chinese machine – well built, simple, and reasonably priced. At the same time, an owner must be prepared to fix mechanical issues and work around software bugs without relying on manufacturer’s support – the folks at Neoden are helpful but due to a time difference a reply to an e-mail would arrive the next day. Fortunately, the user base for these machines is expanding and the thread linked above as well as videos by Ian@DP and other people provide lots of useful info.

I was ready to face issues like air lines clogged by small pieces of styrofoam, non-functioning vacuum pumps and such; luckily, the only problem out-of-the box was racked gantry causing feeding fault. Thanks to this post in DP thread I was already aware about the symptoms as well as the fix – so I fixed it. While doing this I learned that to implement the fix no tools were necessary – a typical human finger jammed between the front support and the gantry works just as well as originally specified screwdriver.

I loaded some tapes and proceeded to stuffing boards. During test runs double sided removable scotch tape placed over the pads helped keeping parts in place. “Removable” type is preferable since it leaves no residue. Also, since the machine has no vision, accurate board registration is paramount. Here is how I do it.

The machine has a laser pointer shaped as crosshairs. With this shape it is easier to aim if a reference board feature AKA fiducial resembles a cross. When there is no fiducial, a reference point can be produced from existing land pattern, as follows.

A picture below shows the Eagle file for a panel of USB Host Minis. Each board contains MAX3421E chip packaged in TQFP-32.

A panel of USB Host Minis

Next picture shows closeup of MAX3421E land pattern on lower left board in the panel. I need coordinates of intersection of a grid lines passing through centers of pads 16 and 17. The coordinates can be derived from the library part (it is X of pad 17 and Y of pad 16 subtracted from the position of the center of the part itself) or simply read from the Eagle screen by placing a cursor on the intersection. This gives me one fiducial. Second one can be obtained from the MAX3421E land pattern on the upper right board in a similar manner.

Reference point

After that, both pairs of coordinates can be used to produce fiducial parts in a placement file ( see DP TM220A wiki for more information about file format). Here’s the fragment of mine:

109,1,0,7,18.5,0,0,1,F1,Fiducial1
110,1,0,99.68,57.7,0,0,1,F2,Fiducial2

When file is loaded in the machine the parts can be used to check/adjust board alignment. Next picture shows laser pointer showing position of Fiducial1. The difference between tinned pad and surrounding solder mask is clearly visible, especially when USB microscope (not shown) is used.

Board alignment

After one diagonal point is aligned the machine can be moved to the second one to check. The issue with registration on this machine is that one side of a board will always be parallel to the gantry. Some of my boards are cut at a slight angle due to the boardhouse being sloppy – for those I will need to fabricate a jig which would allow board rotation. This is going to be my next project. Stay tuned!

Oleg.

Fan regulator

Some time ago I realized that I need to add digital oscilloscope to my set of instruments. DSO is handy for measurements and taking screenshots and this is what I have been doing a lot lately. After comparing specs of current models from several manufacturers I picked Hantek DSO5102B scope. The [...]]]>

Hantek DSO5000 screen

Some time ago I realized that I need to add digital oscilloscope to my set of instruments. DSO is handy for measurements and taking screenshots and this is what I have been doing a lot lately. After comparing specs of current models from several manufacturers I picked Hantek DSO5102B scope. The main reasons to choose this model were cost, screen size, and rich potential for hacking – in no particular order.

Hantek DSO5000-series scopes come in 3 bandwidth variants – DSO5062B(60MHz), DSO5102B(100MHz), and DSO5202B(200MHz). They are identical or nearly identical (early production scopes of different bandwidth had different value resistors soldered in analog front end but that’s the only difference), and making one from another is a simple matter of editing certain configuration files inside the scope. In addition to that, many other modifications can be made, including fan speed, low jitter ADC clock, low noise power supplies, and many others (see the EEVblog thread – the first link in the list at the end of this post). Newer benchtop DSO/MSO oscilloscopes from Hantek are based on the same hardware and there were successful attempts to make a MSO from this scope by adding a logic analyzer PCB.

As is often the case with Chinese products, the oscilloscope is also available under brand names Tekway, Voltcraft and some others with model numbers different from Hantek. The firmware has been originally developed by Tekway and uses Tekway model numbers – DST1062B(60MHz), DST1102B(100MHz), DST1202B(200MHz). Out of many brand names, Hantek seems to be the cheapest. Also, where I live (the US) Hantek can be bought locally. When I was shopping around, 60MHz models were more expensive than 100MHz so I ended up buying DSO5102B from Hong Kong for $388.88 shipped by UPS Global Express.

After receiving the instrument I checked the functionality. The scope worked well, the screen was large, and bugs were tolerable. I then proceeded to “modify” the device to 200MHz model; what follows is the detailed description of the steps I took to implement the mod outlined in EEVblog thread (Tinhead, you are the man!) – proceed at your own risk! The instrument has no “warranty void” stickers and I’m assuming that from the warranty standpoint opening the case is OK but I never bothered to actually check this assumption. In the worst case the instrument would have to be shipped to the seller/manufacturer for repair or replacement. Also, the procedure involves operating the device with power supply exposed – please be careful!

Step 1. Backup

100MHz risetime

First thing to do before making any firmware modifications is to establish known good state in case the mod is unsuccessful and a roll back is necessary. The backup is done to a USB flash drive. Download the Tools_B_models.zip archive, extract it and read how_to_backup.txt in Backup_B_models subdirectory. Then copy dst1kb_b_backup_tool.up file to an empty USB flash drive (128Mb or larger) and insert the drive to the USB connector on the front of the instrument. Wait for the floopy icon on the top of the screen to change color to blue, then press “UTILITY” button and then “F2″. Even though the function name is “Firmware Update” the file on the USB drive doesn’t update anything – we are making backup. Follow instructions on the screen, wait for backup to finish (it takes a while, don’t panic), then copy the contents of the flash drive to a safe place.

It is also a good idea to test the capabilities of the instrument before the mod. To do this I connected very fast pulse generator ( <100ps rise time ) to channel 1 of the scope and took the following screenshot. The fastest timebase setting is 4ns/div and measured risetime is 2.7ns.

Step 2. The Mod

As I mentioned, 60, 100 and 200MHz scopes are all the same; to change the bandwidth several files need to be modified. The scope runs Linux internally and serial console connection is available on the main PCB. In order to access it, I needed a) remove the case and b) pull the EM shield from the main PCB. The case can easily be removed by unscrewing 4 screws, two next to retractable front legs and other two under the carrying handle. Link #3 has pictures showing locations of the screws.

The shield is secured by 5 screws – 2 at the top and 3 at the bottom. After screws are removed the shield can be pulled off without much difficulty. With the screen facing away the input stages are on the left under another shield and the console connector is to the right of the input stages.

Since I was curious about my input stages I pulled the shield from them as well and took a picture. What I needed to know were values of certain resistors around the variable gain amplifier – see link #1 for detailed discussion.

The following picture shows the oscilloscope with the case and shield removed. A place where to look for console connector is pointed at with an arrow.

Console connector Location

Next picture is a closeup of the connector. My copy of the scope has this place populated with a pin header therefore connection is very easy. Positions of relevant signals are shown – they need to go to 3.3V USB to serial TTL converter (I used Sparkfun FT232R Basic Breakout). Note that Tx pin on the board must go to Rx pin of the converter and Rx pin on the board must go to Tx pin of the converter. This picture shows converter connected to the board.

Console Pinout

It’s now time to start hacking. A terminal session to the USB to serial converter’s COM port needs to be open – the serial port parameters for the terminal are 115200, 8N1. Then, the power must be applied to the scope. Again, be careful with exposed power supply! Because the instrument is lightweight it is difficult to plug anything into it with one hand. This is what I did: first, I made sure the power cord is disconnected on both sides, second, I pushed the power button in, and lastly, I connected the instrument end of the power cord, and then the other end – I’ve never even touched the powered device .

The oscilloscope will now start booting Linux OS. After some time, the output will stop; after pressing ‘Ctrl-C’ I got the following message:

Please press Enter to activate this console.

which I did. After pressing ‘Enter’ I got a console prompt on the screen which looks like this:

[root@Tekway-dso /]#

We are now in the root directory. Enter ls command. My (already hacked) root directory looks like this:

[root@Tekway-dso /]# ls
OurLanguages      fpgabank.conf     lost+found        tdc_edge125M
bin               help.db           mnt               tdc_overtime125M
chk_base_volt     home              msg               tdc_pulse125M
cur_acq.type      i2c.log           mult_adc.log      test
dev               icon              nfs               tmp
disk_sta.info     keyprotocol.inf   opt               tmpdst
dn.rbf            language.img      param             ubdb.swi
dso               lib               proc              usbsavefile.tmp
dso.exe           linuxrc           protocol.inf      usr
dst1202b          logo              sbin              var
etc               logotype          sys.inf
fpga.exe          logotype.dis      tdc.log
[root@Tekway-dso /]#

As can bee seen, the directory contains file named dst1202b – this is an indicator to the firmware to treat the hardware as 200MHz instrument. Lower-bandwidth instruments will have a file named dst1102b or dst1062b. The file itself is empty, only file name matters. First step of the hack is to change the name. The Linux command to do this (for 100MHz scope) is:

[root@Tekway-dso /]#mv dst1102b dst1202b

Next step is to modify 4 files to contain the new name. The files are sys.inf, tmpdst, logotype, and logotype.dis. In the first three files, the ‘dst1102b’ needs to be changed to ‘dst1202b’, the fourth depends on a vendor, mine contained ‘hantek_DSO5102B’ and needed to be changed to ‘hantek_DSO5202B’. The vi editor is available, it is not very user-friendly so if you are not familiar with it I suggest reading the manual and practicing using it first on some other Linux system. In any of the files, only one symbol needs to be edited, so general sequence of keystrokes after opening the file is this: using the cursor keys, position the cursor under the character ’1′ which needs to be changed to ’2′, press ‘r’, then ’2′, then ‘Esc’, ‘:’, ‘w’, ‘q’, and ‘Enter’.

After all files are changed, I simply rebooted my scope and enjoyed extra bandwidth. The following screenshot shows the same fast pulse that was used for baseline measurement – I now have 2ns timebase setting and ~1.8ns measured rise time.

Modified instrument maintains the “new” bandwidth after loading official firmware updates. This is just the first of many possible hacks – stay tuned!

Oleg.

Links to information about Hantek scopes describing this and other hacks:

• Tinhead’s EEVblog thread containing current information about the mods
• Das Oszi project page
• Uwe Hermann’s page

At the end of February I received an e-mail from Jingfeng Liu of Linksprite informing me that they are launching a new product called pcDuino and offering a free sample. Two days ago I got a package in the mail containing the board, a WiFi dongle and a [...]]]>

pcDuino board out of the box

At the end of February I received an e-mail from Jingfeng Liu of Linksprite informing me that they are launching a new product called pcDuino and offering a free sample. Two days ago I got a package in the mail containing the board, a WiFi dongle and a bag of cables. In ten minutes, most of them spent looking for spare keyboard and mouse, the system was up and running.

pcDuino is a mini PC platform based on 1GHz ARM Cortex A8 processor. It has 1GB of RAM, 2GB of Flash, 2 USB Host ports, 1 USB OTG port, HDMI video, Ethernet and Micro-SD slot. It comes with Ubuntu pre-installed and its graphic desktop is surprisingly responsive for such a small machine.

After an uneventful start – all you need to do is connect a keyboard, mouse and HDMI monitor – I started looking into ways to control my pcDuino remotely. Ethernet worked out of the box so physical connectivity was not really an issue. However, I haven’t found any access control tools and even root account is set up with no terminal password (and in KDE, the root password is ‘ubuntu’ – I managed to guess it at first attempt without ever looking in the doc). No remote access tool were installed either, which was actually a good thing since I needed to secure the root account first.

Even though pcDuino comes with graphic desktop, I prefer working with command line. I launched the LXTerminal application from the desktop and typed sudo su. This command switches current user to root. Now it’s time to give it a password. The command for it is passwd. It will prompt for a new password and then will ask to confirm. The root is now password protected.

Now I needed an account for myself. On Linux machines my nickname is ‘felis’ so I typed:

adduser felis

The command asks several questions, one of them being a password for the user. Once this is done, I need to add myself to administrator group – this will allow me to use sudo from my account. The command is similar to the previous one and looks like this:

adduser felis admin

The next step is to find out the IP address of Ethernet interface. The pcDuino is connected to a router which acts as DHCP server assigning dynamic IP addresses to the hosts on the LAN. I typed

ifconfig

and saw the following output:

1
2
3
4
5
6

eth0      Link encap:Ethernet  HWaddr ea:54:d8:39:2b:f7
          inet addr:192.168.255.25  Bcast:192.168.255.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
...
(truncated)

inet addr is my IP address. Typically, DHCP server tries to assign the same IP address to the host if it has enough addresses in the pool so I expect my Ethernet interface to have the same address after reboot. I now know the IP address to connect to and it’s time to add a service.

To install ssh, first I needed to update repositories by typing

apt-get update

After the update is finished (this could take a while), I installed ssh, like that:

apt-get install ssh

and also Joe text editor:

apt-get install joe

With just installed editor (hardcore UNIX types may prefer using vi instead) I opened sshd_config by typing

joe /etc/ssh/sshd_config

and adding what looks like line 12 in the following listing. It instructs ssh server to only allow user felis to login via ssh. Once the line is added, press Ctrl-K and then X – this will save the config.

1
2
3
4
5
6
7
8
9
10
11
12

ServerKeyBits 768
 
# Logging
SyslogFacility AUTH
LogLevel INFO
 
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
 
AllowUsers felis

The simplest way to apply new config is to reboot the machine by typing

shutdown -r now

After the pcDuino has rebooted, I launched putty on my desktop PC and opened a shh session to the IP address I discovered earlier. At the prompt, I entered my username, password, and was logged in. I opened another window, tried to login as root and was denied access, as expected. The ssh works just like I wanted.

The next step is to configure Wi-Fi adapter. Unlike Ethernet it won’t work out of the box – the device gets initialized and goes up but it refuses to associate with the access point. For now, the pcDuino sits atop of the router powered from router’s USB flash drive port. Once I figure out how to configure Wi-Fi, I’ll write another post about it – stay tuned!

Oleg.

Bit reversal code

Add-on boards AKA “shields” greatly expand the capabilities of standard Arduino platform. Typically, a shield adds a specific peripheral interface; if you need several peripherals you may need to use several shields. The biggest problem in this approach is shield compatibility. Shield developers don’t care much about interoperability and [...]]]>

WiFi and NFC shield stack

Add-on boards AKA “shields” greatly expand the capabilities of standard Arduino platform. Typically, a shield adds a specific peripheral interface; if you need several peripherals you may need to use several shields. The biggest problem in this approach is shield compatibility. Shield developers don’t care much about interoperability and sometimes making several shields work together is difficult. In the previous article on the topic I described a project where USB Host and WiFi shields were made to share the same SPI bus. I have been recently tasked with similar project which required rather heavy hardware modifications. This article shows the necessary steps to build a system consisting of Arduino board, official WiFi Shield and Seeedstudio NFC Shield.

Here is the hardware configuration. Both shields come with stackable headers so they can be plugged into each other. Both shields use ICSP for SPI but connectors are non-stackable so at least one of the shields must have its ICSP connector replaced with the stackable variant ( I sell them). Also, both shields use pin 10 for CS so this pin needs to be re-assigned on one of the shields.

NFC shield has offset female connectors therefore if another shield is placed on top of it ICSP connector won’t mate. It means that stackable ICSP connector shall be placed on WiFi shield. At the same time, since NFC Shield does have a second row of contacts re-assigning pin 10 on this board is easy.

Before we start cutting traces and desoldering connectors, let’s establish a baseline or “a known good state”. I simply grabbed an example from NFC shield library distro called readMifareMemory, compiled, loaded and ran it. I was able to read the card and now I know that my NFC shield is functional.

One other note – both shields are assembled using lead-free solder which has higher melting point. Don’t forget to set the temperature of your soldering iron accordingly – between 700F and 750F.

Pin 10 removed

Pin 10 re-assigned

Cutting a CS trace on NFC shield is not convenient – the trace is thin and has ground plane close to it. Instead of cutting it, I simply removed the pin 10 from the header to break the connection between this pin and Arduino. Next two pictures show the mod. First, remove the pin by heating it up with a soldering iron from the top and pulling it down with a small pliers. Heat up the pin until it starts moving then pull quickly (but gently). When the pin is removed solder a jumper between pins 9 and 10 on the NFC shield.

Now it’s time to test the mod. In the sketch, find a line near the beginning which looks like this one :

#define PN532_CS 10

and change ’10′ to ’9′. Then compile the sketch, upload and run. The sketch should function just like before the mod using just modified CS at pin 9.

The next step is to modify the WiFi shield. What we need to do is replace the standard 2×3 ICSP connector with one which have long pins facing up to mate with the shield placed on top of it (see previous article on the topic for pictures). The modification must be done very carefully – a damaged PCB often means the whole board is ruined. The following procedure typically works well:

1. It is much easier to desolder pins one by one. On the left picture below the black case is pulled off the connector exposing the pins. This can be achieved by carefully prying the case out working from the sides of the connector between case and a spacer underneath it with a pair of small screwdrivers.
2. When this is done, the shield can be turned upside down and pins pulled one by one using the technique used earlier when removing pin 10 on the NFC Shield. One of the pins is soldered to the ground plane and it needs more time to heat up – be prepared for it and don’t start pulling out the pin before it’s loose.
3. The picture below on the right shows the empty place on the board with excessive solder cleaned from holes with a toothpick. It also shows the connector I just removed and put back together – perfectly usable.
4. The stackable 2×3 connector can now be placed. Before doing this it is a good idea to assemble the stack and see if anything else needs to be added. My copy of WiFi Shield has extra long pins so I needed to add a spacer between 2×3 connector and the board – see the title picture. Put it on 2×3 connector pins, insert the connector and solder it on paying extra attention to the ground pin, as ususal.

2x3 connector removal

2x3 cleanup

The last step before using the setup is to run checks once again. The stack can be plugged into Arduino which at this time should still contain NFC sketch. Running this sketch once again would ensure that the NFC shield can communicate via the new connector. After this is done, WiFi shield can be checked as well using any of the sample sketches from the WiFi library.

This finishes the hardware modifications. Now it’s time to write the code which uses both devices to check compatibility between libraries. If anything interesting comes up, I’ll write about it.

Oleg.

This is short but very important announcement. Kristian from TKJ Electronics started a documentation project – here is the link to the post on his blog. Kristian configured Doxygen and set up the framework to build the documentation from the source code of the library. In addition to all that, [...]]]>

USB Host Library Documentation

This is short but very important announcement. Kristian from TKJ Electronics started a documentation project – here is the link to the post on his blog. Kristian configured Doxygen and set up the framework to build the documentation from the source code of the library. In addition to all that, Kristian documented all the code he has contributed to the USB Host library 2.0. Results can be seen here.

Documenting a function is now as easy as adding a specially-formatted comment at the beginning of the function. In the near future, I will start adding comments to the core USB functions as well to help people understand the internals of the library. It is going to take a bit of time to document everything but even what is available now is a very good beginning – thank you, Kristian!