After some exhausting debug sessions I found several issues.

1) Check your installation
… especially after some late night hacking sessions. For example this cable

2) Check for common Ground
Ground is the reference point for the data lines. With different cable lengths to the power supply you can have major potential differences, this is kinda bad. In this example the ground cable is NOT routed:

Good Cabling, the ground cable is routed:

3) Use a dead simple circuit simulator
Check http://www.falstad.com/circuit/ for a simple and easy to use circuit simulator, thanks for this Java application! Great to debug your hardware circuits.

4) SPI Buffer (74AC245N) to improve the SPI Clock Signal
The only problem left were the two last modules, they just flicker from time to time. Thanks to Andre Zibell from the http://www.ledstyles.de board, he designed a busdriver to clean a (SPI) signal with a 74AC245N IC (Cornerpinning busdriver):

Andre was kind enough to send me two PCB’s, unfortunately I don’t really like (can?) solder SMT components, thats why I had to use a breadboard. I found BlackBoard breadboard designer very useful:

I build my first prototype on breadboard:

I installed the buffer breadboard after 4 large modules, the result was disastrous! No LED was blinking correctly after the breadboard, so I hooked up my DSO Quad and took a look at the signals:

• The buffer breadboard is working, the signal flanks are steeper
• The signal is already greatly distorted, I need an earlier buffer breadboard. The signal flanks are too weak to form a clean “up” signal, so they get crippled

I use an 1 kOhm resistor between Clock and Ground, this improved the clock signal.

5) SPI Speed
The faster the SPI sig­nal is, the more vul­ner­a­ble it is. Take a look at this chart:

If your hardware (cable length…) is not optimal, reduce the SPI speed. This sounds very easy in theory, but its more difficult in practice, especially if you have an ISR to shift out some data, take a look at this real life example:

The code above was working fine, but the last modules were not working fine. I reduced the SPI clock speed to 0.25MHz but the update speed was extremely slow. I did some experimenting and found out that I had to lower the CPU usage:

This was finally the solution (don’t forget the 1kOhm resistor between CLK and DATA!), without additional hardware (speak: no SPI buffer)!. After countless hours, the installation finally works!

Other notable remarks:

• Never EVER prepare cables on your own!
• Create a project log, so you need to search each bug only once…

Thanks to LED Styles and Dangerous Prototype for your help!

Make sure you can connect your battery by checking THIS forum thread.

You can find the official Quad manual (DSO Quad v2 6 Manual 0.92b.rar) in this thread.

I own the v2.6 Hardware running SYS v1.51 and APP v2.52. I downloaded the application firmware file AP3_P100, checkFirmware Upgrade Wiki for a detailed firmware update. Then I started the DSO Quad in the “Firmware Upgrade Mode” (press “> ||” during startup). The I copied the AP3_P100.hex (Note: the unzipped file!) file to the USB disk and waited until the file gets renamed to AP3_P100.rdy). When the file gets renamed, power cycle your Quad to finish the upgrade process.

Here is an overview what kind of Keys the DSO Quad has:

• Run/Hold: is used to control working state of Quad: Working or Pause
• Calibrate: Press more than 2s to enter the calibrate mode if the active menupoint is a analog input.
• Preset: Save current setting (Signal Generator, Time dimensions?), they are loaded each time the Quad is started. Handy if you, for example, want to mute the beep.
• Sine Wave: Used to save a Screenshot
• Navigator B:Navigate in the main menus. Press change the Menu entry while push/pull change the current setting.
• Navigator A: Navigate in the submenu (after a menu was selected with Navigator B).

Calibration
You need to calibrate the device itself and the probes. You need an external power meter and a very fine screwdriver, I miss both utils so I didn’t adjust my DSO Quad yet.

Edit: the hifiduino blog entry about the Quad have some great tips about calibrate the device:

“One needs to know that the probes that come with the unit are not compensated. After quick schematic review I figured out that C3A and C5A adjust compensation for channel A, and C4A and C6A for channel B. These trimmer caps are accessible under the battery, btw”

• Use the built-in signal generator to generate a square wave. 10KHz is a good frequency to see the overshoot
• Connect one probe to the signal generator output and one probe to channel A or channel B (there is no need to connects the GNDs but you can connect them if you wish). Feed the signal to channel A (or channel B)
• In order to adjust the compensation capacitors you need a plastic screwdriver. Since I did not have one, I took a pen cap and sharpened the little plastic stick of the pen cap with sand paper
• Turn/adjust the caps until the overshoots are eliminated as shown in the picture below

Waveform generator
Some facts about the Waveform generator I found on the Forum:

• the output should be about2.6~2.8 Vpp
• a guy reported this issue in the Forum: “It correctly outputs a square waveform at any frequency 1Vpp. But when trying to set any other waveform, all I get is a square waveform with some modifications at the top part which vaguely reminds of a sine or sawtooth or triangular waveform but has nothing to do with any of them.“
  The waveform looks like this:
  

  I this case your DSO Quad has a hardware defect! (Unfortunately in my case the problem was not the double zener D6, but the op amp U7.)

Save Waveforms as BMP / Screenshot
Edit 21.3.2012: This step is obsolete!
In order to save a screenshot of the Quad, you first need to create some BMP Files and copy them to the internal 2MB USB Disk. The BMP Files need to have a resolution of 400x240 and a bitdepth of 4 (32Bit). I found the file “Save wave for DSOQuad.rar” on the Seeedstudio Forum, here is the readme:

Use Navigator B to select the “Save File” dialog, then press the “Save Wave” Button.

Memory Slots:
The Quad has 4 different Memory slots, each slot can contain a different Application. The stock firmware is installed in Slot 1. You can select the slot by pressing a button during startup:

3rd Party Firmware:
Hint: Firmware update on OSX does not work! OSX fills the disk with hidden files, the DFU disk appears/disappears in a 3s interval. My USB disk is also filled with garbage, I had to reformat it (on a Windows machine)

• DSO203 GCC Community Edition (installs in slot 1). You also need the SYS from Marco Sinatti
• https://github.com/gabonator/DS203
• Frequency response application (installs in slot 4)
• Logic Analyzer (installs in slot 3)
• Tetris (installs in slot 3)

Conclusion:
After working/playing with my Quad for about 3h I must say I can work with it. However the navigation is not very intuitive, maybe I change my mind if i keep working with the Quad. If you need an Oscilloscope now and then and you’re not operating in the GHz range, the Quad is a nice tool! However, never ever connect the Quad to OSX, the Quads internal SD memory get messed up. You need a Windows (or Linux) OS if you want to update the Firmware or get images from the Quad.

References:

• http://essentialscrap.com/dsoquad/freq.html
• http://hifiduino.wordpress.com/2011/04/30/dso-quad-quick-start-guide/
• Seeedstudio Forum
• Seeedstudio Wiki
• http://www.valky.eu/?data/hardware/ds203.txt
• Top 10 Things to Consider When Selecting a Digitizer/Oscilloscope

Competitors:

• QA100, Dual Analog Channel w/10-bit ADC, 100 Msps, Deep Buffers and 12 Digital Channels, $349
• Rigol DS1052E
• Picotech USB Oszilloscope

My new project looks like this:

Total cable length: 50cm internal cable per unit (4m), the connecting cable measures 2m and 7 connecting cables à 70cm makes a total of approximately 11m.

In the beginning I was using the bit banging LPD6803 firmware. That worked quite ok, but the update times were not very fast and there were some visible glitches (white flashing aka. ringing). Fading all Leds from black to white was not working at all, very much noise (random color) was visible!

So I start using the new SPI LPD6803 firmware which should update the LED Modules much faster (only MOSI and SCLK pins are used). The first unit is working very fast and clean, however between unit#2 and unit#7 I just see flicker… looks like the cables or connectors make some trouble here.

According to the LPD6803 datasheet the chip provides “Adopt self-add token-ring technology dual shift line, shift clock can reach 24MHz” and “Data clock signal is drived strongly to next chip to enhance level after built-in phaselock circuit”.

I use a LPD6803 based Led Module which looks like this:

This assumption would match the scheme from the lpd6803 datasheet:

Now let’s take a look at the SPI “Standard”.

The serial peripheral interface (SPI) bus is an unbalanced or single-ended serial interface designed for short-distance communication between integrated circuits.

…aha, guess 70cm of unshielded cable does not really match “short-distance communication between integrated circuits”. Anyway I searched some common issues with SPI communication:

• Noise on the DC level
• Impedance of the SPI lines.
• Reflexion of the SPI signal due missing or wrong termination resistor, the RS-422 standard suggests a 100 Ohm resistor.
• Use twisted-pair cable, because the conductors of twisted-pair cable are closely electrically coupled, external noise induced equally into both conductors appears as common-mode noise at the receiver input. You can use each SPI line sent in a twisted pair (SCLK/GND, MOSI/GND)
• Cable length is too long compared to the SPI frequency

Back to my modules, compare the common issues with my situation:

Noise on the DC level:
A possible issue, the capacitor on the LED module is just used to prevent a AC less voltage on the LPD6803 IC. According to the scheme, the 12V is applied directly to the LED diodes.

Impedance of the SPI lines:
I do have some issues here. I first added a 50Ohm and 220Ohm resistor between SCLK and ground, the result was bad (no more animation), I guess the resistor was too low, thus the CLK signal vanished. Then I added a 1 kOhm resistor, the animation was working fine! So I started to add a 1 kOhm resistor on the other units. The Leds were working, however the more units I connected the more flicker was visible…

Reflexion of the SPI signal/Missing terminator:
As the output of the Led module contains two 51Ohm resistors I guess this issue can be ignored.

Use twisted-pair cable:
I want to avoid this point, as I already soldered the cables and connectors.

Cable length:
Assuming a typical signal velocity of 5ns/m, a 11m cable will cause a propagation delay of 55ns. The full wavelength of a 1Mhz singal is 300m, for 8Mhz it’s 37.5m and for 16Mhz it’s 18.75m. So if I choose an SPI frequency of 1 or 2Mhz the wavelength can be ignored.

Conclusion:
The problem still exists and I need more experimenting until this issue gets resolved. I test the installation with different SPI speed settings and need to test further.

Concrete next steps would be:

• Experiment with different “impedance” resistors.
• add capacitor on each unit to clean DC (what capacity should be used? Elkos? Ceramic ones?)
• Add termination resistor?

I asked some clever people on Reddit and on Dangerous Prototypes, here are some promising answers:

• flinxsl/reddit: At only 1MHz you can get away with a lot of approximation. It is a push-pull interface unlike I2C, so no termination pull up/pull down resistors are required.
  As others have mentioned, you should try looking at the signals with a scope, but be warned a probe can cause ringing that wouldn’t be there otherwise.
• Brian/dangerousprototypes: I know you say you want to avoid it but a good transmission line is needed for a long distance at a high speed.
   
  Even your single wires are transmission lines they are just to a ground very far away. They are very inductive this way and that means very very slow.
  The wavelength is shorter than you state, as your wavelength is assuming a impedance of free space and not of the transmission line you have. 100 Ohm is typical for twisted pair. 75 or 50 for coax. This means longer wavelengths as frequency does not change but the velocity is less.
   
  Terminating a poorly defined non-transmission line with any impedance is does make a lot of sense to me. (If they aren’t twisted as the loop size changes the impedance will change).
   
  Even without adding ground returns some progress can be made by twisting the 4 wires you have. I would twist the CLK line around GND and the data line around Vdd. Both GND and VDD are DC so from a transmission line viewpoint they are ground. If you have enough capacitance at each end it might be okay.
   
  For reference, if you want long transmission the best thing would be differential buffers on each end, failing that single ended with ground returns for each line. Like a ribbon (IDE) cable or a CAT5 cable.
• Bertho/dangerousprototypes: …The capacity is normally what limits the clock frequency. Rule of thumb says you have 100nF per km of cable (may be worse or better; see cable docs). It takes a lot of energy to drive capacitive loads. You also have signal degradation due to cable resistance. If you get to higher frequencies, you will encounter coaxial properties of the cabling and then you must ensure that the driving impedance matches the loading impedance and the terminating impedance (all must be equal)…
   
  The capacitance you need to add at the local tap’s power depends on the load current variations and the cable resistance. The impedance of the power supply lines increases as you add more cable and that means you need to decrease the impedance locally with a polarized capacitor (order of 10..1000uF). The ESR of the capacitor should be low. How low depends on the load current changes. A second capacitor is a ceramic of ~100nF to short the high frequencies.

  You may also want to add a ferrite bead at each tap’s power outtake. The effect of the inductance is that the rush-currents are damped and will not feed back as much. It also reduces the capacitance requirements at the local taps

• jwhat/reddit: So first piece of advice: if you have access to an oscilloscope, take a look at the data lines. Are they ringing? Are the signal levels too low?

Appendix:
The Arduino supports different SPI Speed:

A quote from the LPD6803 Datasheet:
“Terminal is designed to push-pull strong drive circuit, after testing, it can drive 6meters length signal line when clock is 2M, to prevent signal echo, normally, pls serial a 50Ω resistance at DOUT and DCLKO, then output to next step.”. As you can see on the image, those resistors exists

Various other quotes:

With long lines and steep slopes, one has to use impedance matching at the ends of the lines. Without properly terminated lines there can be ringing, which is particulatly bad on the clk line. Once using terminated lines and resonable drivers there is not much need for repeaters in between, unless you really go over 100s of meters. [src]

Add series or parallel termination ONLY to SPI clock signal to ensure clean edges. SPI clock edges must be clean, but SPI data does not have to be clean. Reduce SPI clock frequency to allow SPI data signals to settle, meet setup time to SPI clock edges. Use a 33-ohm series term resistor only on SPI clock (SCLK) signal to ensure clean signal edges, and possibly reduce SPI clock frequency (if necessary) so that SPI data (in either direction) meet data -> clock setup timing. [src]

Used references:

• http://www.nerdkits.com/videos/multipanel_spi_ledarray/
• http://wiki.electronics-irc.net/Long_Distance_SPI
• http://www.ti.com/lit/an/slyt441/slyt441.pdf (Extending the SPI bus for long-distance communication)
• http://www.ti.com/lit/an/slla142/slla142.pdf
  (Extending SPI and McBSP With DIfferential Interface Products)
• http://www.csgnetwork.com/freqwavelengthcalc.html
• http://www.ledstyles.de/ftopic18880.html
• Serial Protocols Compared

Signal Transmission
Two common modes of transmission:

• symmetrical / Differential signaling (RS422, USB, Ethernet…) harder to implement, more wires (2n) but resistance to electromagnetic interference.
• asymmetrical / single-ended signaling / unbalanced (RS232, I2C, SPI…), easy to implement, only n+1 wires but susceptible to interference.

Cable Types
Twisted pair cables canceling out electromagnetic interference (EMI) from external sources. You can couple a AC with a DC signal (asymmetrical use case, for example V+ with Data and GND with Clock) or a AC with an AC signal (symmetrical use case, for example Data+ and Data-).

*** Edit 20.3.2012 ***
I created some reference shot with my DSO Quad, I used a Arduino UNO as board and my SPI firmware.

SPI 1MHz, Arduino SPI Output, Clock only:

SPI 1MHz, Arduino SPI Output, Clock and Data (Strip.update):

SPI 1MHz, End of a 20 LED module strand, Clock only:

SPI 1MHz, End of a 20 LED module strand, Clock and Data (Strip.update):

The signal at the end of 20 LED Modules does not look very clean, however the signal is NOT terminated.

Here is the simple code I used to measure:

Description of the LPD6803 timing sequence:

jps, get PID of a running Java process:

 
 
jmap, create memory dumps from a running process.
Example, get PermGen statistics from a running process (if you need to debug some nasty java.lang.OutOfMemoryError: PermGen space errors):

Example, get a heap dump from process:

 
 
jstat, display real time information of a Java process:

 
 
jstack, prints Java stack traces of Java threads for a given Java process or core file or a remote debug server, example:

 
 
Histogram print histogram of java object heap, example:

 
 
Java VisualVM, a nice frontend that can be used to load dump files you created with the jmap tool. This tool also allows you to monitor your application (Heap, Permgen space, CPU, Threads, Classes).

 
 
If you need more information, make sure to check out this technical article at java.sun.com.

Give us dimensions, and we’ll generate a PDF you can use to cut a notched box on a laser-cutter

The final models were laser cutted by http://www.3d-model.ch/, the result is great, take a look at the results:

• WS2801 LED Strips
• An Arduino Ethernet Board and a USB/Serial Light Adapter to upload the firmware
• 5 Volt power supply – I use an old ATX Power supply
• Optional: Grove — Base Shield and Cables

Also make sure that the StripInvaders Sketch is already on your Arduino!

This is my WS2801 LED Strip:

Now it’s time to connect the Grove Base Shield to the Arduino Ethernet:

Almost done, now connect the cable from the Arduino Grove Shield with the LED Strip and the 5V power supply. This should look like this:

Now connect the StripInvader to your LAN and power up StripInvaders. Try to ping the host “invader.local”, this is the mDNS name of the StripInvaders Arduino device.

The StripInvaders can be configured without re-uploading the Arduino sketch, by sending a special OSC messages (/cfg). Take a look at this PureData example:

In our example we send “/cfg 66 5 4 96″. The first parameter 66 is just a magic byte, it must be 66, period. The second parameter defines the data pin, the third parameter defines the clock pin and the last parameter define how many led pixels are installed.

Links: StripInvaders System

Look, it’s really easy ma:

Edit 4.2.2012:
I just released the StripInvaders config Tool (for OSX and Windows), this should simplify the setup process. Here is a screenshot:

• 15 different color modes
• Control StripInvaders with a Smartphone or Tablet
• Stepless adjust the RGB value and the animation delay
• Bonjour and mDNS support
• DHCP support
• All fits into the 30kb firmware
• The firmware is released on GitHub
• Strips available on my PixelInvaders.ch shop

StripInvaders will color up your flat, take a look at those images:

Here is the wiring between BusPirate and Arduino Ethernet
BP GND -> Pin 1 (Black)
BP 5v -> Pin 3 (Red)
BP MOSI -> Pin 4 (Red)
BP MISO -> Pin 5 (Yellow)
BP CLK -> Pin 6 (Blue)

Connect to your BusPirate (115200 BPS) and configure it to run in transparent serial mode

Exit the Terminal and switch over to your Arduino IDE. Now upload your sketch through the BusPirate.

Oh and if you’re asking yourself, where the OSC Gui definitions are, check this link.

I created a OSX Lion Boot DVD (re-downloaded it from the App Store) to reinstall OSX.
After swapping the disks I pressed the d key to boot from DVD. 25 Minutes later my OSX Lion was reinstalled, time to do some tweaks to optimize OSX for SSD drivers.

I installed some tools and noticed that the system was faster, but not THAT faster. In the System information view I saw that the negotiated SATA Link Speed was only 1.5Gbps (SATA1), however my NVidia MCP79 Controller should support 3Gbps (SATA2). After some research I found the solution for the SATA 1.5 Link issue in a OCZ support forum. I downloaded an ISO image from Rapidshare (!!) and patched my SSD drive. The result was very impressive! My boot time is less than 15s and man, I never saw the Eclipse IDE start so fast.

I used XBench to create some Benchmarks. I created some benchmark with 1.5Gbps link (blue) and with the 3.0Gbps link (red), see yourself.

I use the maven-instal-plugin to deploy some I-did-not-find-them-in-public-repos libraries, the pom.xml looks like this:

Now long story short I found a bug entry on jira which was not directly
related to my issue. However due lack of options I thought lets update the aether libraries on my system. Maven v3.0.3 uses v1.11 while v1.13 is currently the latest version. Delete all v1.11 jar files and replace’em with a v1.13. Now maven works as it should. Or wait for Maven v3.0.4…

Aether binaries: http://repo1.maven.org/maven2/org/sonatype/aether/
OSX Maven v3.0.3 library path: /usr/share/java/maven-3.0.3/lib

PixelController supports well-known industry and OpenSource standards, such as Art-Net, Mini-DMX, LPD6803 and Seeedstudio’s Rainbowduino. It is quite simple to support more standards protocols like WS2801, HL1606 etc.

If the PixelController software is launched, two windows are displayed. The first window shows the internal debug buffer while the second shows the simulated output matrix.

The internal imagebuffer in this example shows three different visuals. The number of visuals displayed corresponds to the configured output:

The simulated output matrix window shows the first Visual stretched over two matrices:

There are different possibilities to control PixelController, one of them is the PureData frontend:

Another possibility to control PixelController, using the simple TCP protocol with NetCat:

How to get PixelController?

PixelController is hosted on GitHub, so

• Browse the Source
• or download a version 1.0.3
• or check PixelInvaders Website for more information

Technical Specs

More information about PixelController.
Generators:

• Blinkenlights Movie Player
• Image Viewer
• Simple Plasma
• Simple Colors
• Fire
• Metaballs
• Pixelimage
• Texture Deformation
• Textwriter
• Image zoomer
• Cell
• Plasma Two
• FFT
• Bubble

Effects:

• Inverter
• Rotozoomer
• Horizontal Beat Shifter
• Vertical Beat Shifter
• Voluminize
• Tine
• Threshold
• Emboss

Mixer:

• Add Saturation
• Multiply
• Mix
• Negative Multiply
• Checkbox
• Voluminizer
• Xor
• Minus Half
• Either

Fader:

• Switch
• Crossfade
• Slide Upside Down
• Slide Left Right

Resizer:

• Pixel Resizer
• Quality Resizer

How to control the Software:

• PureData Frontend
• OSC Server/Client
• MIDI Device/Signal
• Command Line Interface
• Simple TCP Interface
• Audio input

Operation Mode:

• Manual
• Automatic aka. Randomizer
• Predefined settings

Supported Operating Systems:

• Microsoft Windows
• Apple OSX
• Linux
• Every OS that supports a JRE

Besides the hardware, the control software was a big task. I created PixelController, a modular software written in Java and released as OpenSource on GitHub.
The frontend is written as a PureData Sketch. That means you can easily adapt the frontend and use OSC applications (like TouchOSC) or Midi devices (like Akai MPD26) to control the software.

Here’s a picture of two PixelInvaders panels, controlled by an Akai MPD26:

Two PixelInvaders Panels in action:

More information / Links:

• I set up the project site at »www.pixelinvaders.ch
• The »PixelController project on GitHub
• I you need such a panel (and who does not?) you can easily »get one at my IndieGOGO campaign

Spread the word, I need support for my Indiegogo campaign!

In this tutorial we use a strand of 20 LPD6803 RGB LED as huge VU Meter. Processing will send serial data to the Arduino which will display it.

The source can be found on my GitHub site.

Check out my PixelInvaders Shop if you want to buy some LED strands!

Take a look at ladyada’s very informative post about the LPD6803 module.

So where to buy these Intelligent, LPD6803 based Pixels? At my PixelInvaders Shop for example!

Needed Hardware:

• An Arduino Compatible Board
• A 12V Power supply (an old ATX Power supply is perfectly fine)
• A strand of some LPD6803 based LED modules
• Some cables to connect the LPD6803 module

I had some cardboard angle laying around an thought, why not build a DIY Wall Washer.

Links:
- LPD6803 LED module shop
- All source files on GitHub

Two Videos showing the Wall Washer in action. Note: The Wall Washer looks brighter in reality.

http://www.shopify.com — not free, used as reference

http://www.foxycart.com/ — only free during development
http://www.vendder.com/ — nice looking, i18n
http://www.39shops.com — nice looking, payment process it too painfull (region, taxes…)
http://tinypay.me/ — nice looking
http://wosbee.com/ — looks ugly — didn’t try
http://yokaboo.com/ — only one image per product — didn’t try
http://bigcartel.com — 5 products and one image per product — didn’t try
http://www.pipfrog.com — limit monthly visits to 3000 views — didn’t try

http://simplecartjs.com/ — js solution

do YOU have some alternatives?

Download my modified source rxtx-2.2pre5-src.zip
and the Windows and MacOSX binaries rxtx-2.2pre5-bin.zip

Here is the cvs diff.

Build RXTX library for Windows — make sure you installed Visual Studio Express.

We wrote a very simple firmware to perform some basic benchmarks — Paul wrote a simple c tool to measure the native latency, I wrote a simple tool in Java using rxtx lib to measure the latency in Java.

Long story short, here are the results:

Hint: These results are made on my MacBook (Model 5,1), Intel Core 2 Duo, 2GHz, uname output: “Darwin xxx 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386”

Conclusion:

• Java latency is at least 20ms
• The Arduino UNO may be slower than the Arduino 2009 if small a amount of serial bytes (<12b) are transferred
• The Teensy 2.0 board may be up to 18 times faster than an Arduino board

So this 20ms latency using the rxtx library looks quite promising… hmm take a look at this code snipped from the file SerialImp.c:

Replace this 20’000ms delay with a shorter (I used 2000ms), recompile and enjoy decreased latency!

Files used for this article:
- Performance test files
- RXTX TEST library, only 64b Mac OSX!

The rxtx lib is not very well tested (not at all!) — so leave a feedback if the lib is working fine for you!

Anyway, here are the results on OSX with the patched rxtx library:

Update 16.05.2011:
Paul did some more native performance tests, here are the results:

While the serial interface is not a part of the JRE (anymore), the network stack is. This means we can send network packets at full speed. And there should be some Network to Serial tools available for my Mac OSX. Nope! I found plenty of such tools, but not a single one was working:

First I checked the Arduino Playground about SerialIP. A Serial IP library for the Arduino exist — but I couldn’t find a SLIP utility for Mac OSX 10.6.6. There was once slattach — but only for pre OSX 10.6. I compiled the source myself without success.

The next step was another Arduino Playground wiki entry, about SerialNet. To make the long story short, here are the tools I tried without success:

• nc –l –p 4443 –D < /dev/tty.usbmodem621 > /dev/tty.usbmodem621
• ./ser2net –C “3001:raw:0:/dev/tty.usbmodem621:115200 NONE 1STOPBIT 8DATABITS –XONXOFF –LOCAL –RTSCTS”
• socat –d –d –d –x –s –t 30 TCP-LISTEN:4441 GOPEN:/dev/tty.usbmodem621,raw,ispeed=115200,ospeed=115200,ignoreeof
• Tinkerproxy v2.0

Socat v1.7.1.3 hints: the “nonblock” option for the serial device resulted in a “tcsetattr(3, TCSADRAIN, 0x7fff5fbfefd0): Invalid argument” error, I guess this operation is not supported by the OS. Gerhard gave me another hint, that I should use the GOPEN address type (I was using the PTY address type — this *should* create a new PTY and not open an existing one. This is a bug in the v1.7.1.3 version).

Disclaimer: Maybe I was just too stupid to use those tools correct…

The solution was a bit funky — I created a PureData patch. Whats PureData?

PureData is a real-time graphical programming environment for audio, video, and graphical processing.

But you can use it as network-to-serial relay too. Here is my patch as image:

You may download the patch here. Features of the v0.1 release:

• Autoconnect Serial Port
• Autoconnect back to your listening Server
• TCP and UDP supported (replace tcpreceive with udpreceive and tcpsend with udpsend)

Here is the processing sketch I used to test my solution:

And this is the Arduino Sketch:

Here are some performance results on Mac OSX v10.6.6, PureData v0.41.4-extended, Arduino v0022, Processing v1.2.1 — using an Arduino UNO:

Conclusion: Compared to using the rxtx JNI libraries I cannot see a huge performance boost! Sad but true. So my assumption was wrong — JNI is NOT the serial bottleneck using Arduino with the rxtx libraries. Again:

JNI is NOT the serial bottleneck using Arduino with the rxtx libraries

Side note: I read on several forum threads (mainly on the Arduino forum) that the baudrate should not matter is you use the USB version. This conclusion is just wrong! You can use my code above and run the tests with 9600 bps and 115200 bps — you’ll notice a HUGE difference!