Difference between revisions of "Velleman K8062 Upgrade"

Revision as of 07:42, 18 May 2011

~ PRELIMINARY ROUGH DRAFT (and somewhat written late at night) ~

Background

The Velleman K8062 (DIY kit) and vm116 (pre-built) DMX transmitters appear to be one of the most successfully marketed DMX transmitters in the world. A quick internet search reveals this to be true with many distributors world-wide. What is also apparent is that many people have found its performance to be somewhat underwhelming. The performance of this unit has been subject to a lot of discussion on many of the DMX web sites <ref> http://forum.velleman.eu/viewtopic.php?f=15&t=2018&hilit=vm116</ref> <ref> http://www.freestylersupport.com/fsforum/viewtopic.php?f=12&t=1042#p3689</ref>.

Previous attempts <ref>http://k8062forlinux.sourceforge.net/ </ref> have been made to re-write the firmware but the performance problems stem from the hardware / firmware design of the interface itself. Without modifying these the issues cannot be resolved.

This page is set up to provide information on an effort to add 3rd party support for these units in order to provide a full speed DMX interface. The potential is that of a reasonably good DMX transmitter perched somewhere between many of the "open" FTDI based units and more fully fledged firmware based transmitters. Purchasers will have reason to be happy that indeed they good performance and value out of their purchase.

The Technical Issues

The problems of the k8062 really are a legacy of the era of its design. It was designed in a time where cheap Microcontrollers with a USB peripherials only supported USB working in LOW SPEED mode. The original microcontroller used on the k8062 was the PIC16C765 with a LOW SPEED USB only interface. The problem was further exacerbated by the choice to use a HID CLASS USB transport mode which, by definition of the USB HID class specification, places further, crippling, timing constraints.

The Velleman k8062 is a low speed HID device.

What this means is that it may only transfer EIGHT BYTES at a time and only transfer them once per every TEN Milliseconds. This works out to be an effective transfer rate of 800 bytes per second. While for some DMX usages this might be fine and good enough for a few flashing lights. It does in theory allow for a full universe to be updated about 1.55 times a second and at much higher rates when only a small number of channels are used.

For many uses this is just not good enough.

DMX-512 is designed to provide "real time" control to DMX receivers without apparent delays to human perception and has a theoretical maximum transfer rate of ~44Hz for a full 512 channel DMX universe. Without getting to picky about very exact timings the general comparison is:

800 bytes/second Vs 22727 bytes/second or about 3.5% of the maximum bandwidth.

This is why the k8062 chokes on anything other than the most basic DMX set-up and why so many of them sit idle not fit for the purpose they were bought for.

Velleman's Protocol Trick, Making It Better Or Worse

The designer of the original firmware made some attempt to address the poor throughput of their unit. The protocol used between the Velleman firmware and the software uses a simple form of compression in order to increase the speed. What it does is count the number of consecutive zero value channels, (If and when they aline with the start of the payload of the USB packet) and rather than send them as individual channels it instead sends a count of the number of zero channels over the USB HID interface. The firmware then reconstructs the full stream using this "zeroed" channel count plus the rest of the non-zero channel data. This enables faster transfer rates when when the data consists of consecutive 0s..

The way this trick is implemented though is poor and can actually make things worst! The reason why this is so is because the actual number of data packets required to be sent alters depending on both the number of zeroed channels and their place in the stream. On top of this, and as the k8062 protocol works, the last few channels that do not make up one complete packet are then send one at a time. As these one at a time transfers are only scheduled by the PC HID driver at 10ms intervals it is possible that to save sending ONE zero channel an additional SIX channels of data are sent one per packet taking an addition 60ms!

Apart from the reduced transfer speed there is now also an issue of jitter in the data stream and it is very difficult to know exactly how long it will take to send one frame as it can vary by up to 300%!

A New Revision

At some point in the life of the k8062 there was a change over of the firmware chip used. It was upgraded from a low speed 16C765 to a PIC18F2550 capable of FULL SPEED USB transfers. However it appears to be, and verified by several people, that Velleman decided to remain with the LOW SPEED MODE and not upgrade the performance of the k8062. Despite the availability of newer technology that would have allowed for many improvements the k8062 as sold today still works pretty much like the very first units sold.

A Solution In The Offering

A retro fit of new 3rd party firmware is now (MAY 18th 2011) in testing. This new firmware, coded "VX8062," is a complete independent clean room design. It is a drop in replacement for the existing firmware chip and requires no soldering or circuit modifications to work. It is a FULL SPEED HID device offering up to 80 times the transfer rate of the legacy k8062 firmware.

In addition to being a drop-in replacement compatible with the existing Velleman software, it is supported by a BOOTLOADER which allows for reflashing the firmware for further updates, upgrades, bug fixes or customization.

Tests done with the windows based DMX driver Vixen and the new customized DLL plug-in have shown that VX8062 is capable of sending a full DMX universe of 512 non zero channels at a refresh rate of 40Hz. (I.E. 40 frames per second.)

For linux and MAC users to take the fullest advantage of the VX8062, support is now being coded into the OLA framework. This is a joint effort by the chief authors of OLA and the VX8062.

To get the most from VX8062 the transfer size of the HID packets needs adjusting from 8-bytes to 64-bytes per transfer. (Even without this alteration the VX8062 is automatically TEN times faster by virtue of the allowable transfer speeds defined by the HID CLASS USB specification.) There is also some additional protocol commands in the VX8062 that address short comings in the existing protocol as outlined above.

It is hoped that further features can be added to the VX8062 via the in-build BOOTLOADER. One such feature planned is the creation of a USB to WS2801/3 interface to allow control of the WS2801 RGB led interface without the need for further hardware.

Further details coming soon.

<references />