Personal tools
The Open Lighting Project has moved!

We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.

Difference between revisions of "Velleman K8062 Upgrade"

From wiki.openlighting.org

Jump to: navigation, search
Line 1: Line 1:
 
  ~ PRELIMINARY ROUGH DRAFT (and somewhat written late at night) ~
 
  ~ PRELIMINARY ROUGH DRAFT (and somewhat written late at night) ~
Updated 25th May 2011
+
Updated 23rd June 2011
  
  

Revision as of 15:51, 22 June 2011

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

Updated 23rd June 2011


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=10&t=528&start=20</ref>.

Previous attempts <ref>http://k8062forlinux.sourceforge.net/ </ref> have been made to re-write the host driver 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 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 8 bytes <ref>http://www.usb.org/developers/devclass_docs/HID1_11.pdf</ref> at a time and only transfer them once every 10 milliseconds. This works out to be an effective transfer rate of 800 bytes per second. Ignoring the overhead in the protocol this allows for around 1.55 full frame DMX updates every second. For rigs that use a small number of channels or don't require high speed updates this may be sufficient.

For many uses though this is 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 Compression - making It better (but sometimes 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

Inside a K8062, showing the updated microcontroller

At some point in the life of the K8062 the microprocessor was a changed from the low speed 16C765 to a PIC18F2550 capable of full speed USB transfers. However (verified by several people) Velleman decided to remain with the low speed mode and not upgrade the performance of the K8062, probably to ensure backwards compatibility with the units they had already shipped. Despite the availability of newer technology that would have allowed for many improvements the K8062 as sold today still works the same as 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.

Update 25th May.

Preliminary testing has been done on a recompile of the existing Velleman EXE and DLL to allow FULL SPEED transfers at the 80x rate. So far this appears to be working well and it is now entering the Beta test stage. The new software has been tested with FreeStlyer and LightPlayer as well as the simple demos provided from Velleman. The development of this new software has delayed the release of the firmware by a few days but it does represent a huge leap in the development of this update. The new algorithm will be ported to C++ for inclusion in the OLA framework hopefully soon giving this DMX interface broad support across all platforms.

A contact email address will be posted shortly.

Update 23th June 2011.

Sorry for the lack of updates. I have been busy helping out with some open source software while waiting for the chips I need for this project to arrive. Sadly they are still somewhere between Singapore and Australia. Allegedly they were shipped last week so they should not be far off. I have received a very small number of samples directly from microchip and these will be sent ASAP to the more technically savvy who have helped out already. The third lot of chips I ordered arrived overnight only to turn out to be something different from what I ordered. (But to my advantage to keep anyway...) :)

In addition I have been involved in the DIY Christmas lighting community here in Australia just to get a feel of where to direct this project. There are a number of possibilities for further upgrades like pixel support and hyper DMX and other stuff. As this time I do not know how this will fit in but there has been a fair amount of research happening. The important thing for now is to get the chips and send them of to those who are on my beta tester list.

(This list is now closed. Thanks to those who offered.)

Once again sorry for the hold-up but it is coming still.


<references />