Quirks with YET-M1 and USB-Ports

A few days ago, I ordered a YET-M1 Bluetooth Audio Adapter for just a few bucks on ebay. It has a 3.5 mm jack as audio output, you can simply hook it up to any active speaker and make it bluetooth enabled. It can so play the music from your phone wirelessly. It is powered over the USB-plug on the other end, so you just need to plug it in your phone charger.

Well, then I tried it out with an AV receiver, which even has a convenient USB port for flash drives already build in. However, the bluetooth adapter seemed like it didn't power up. The same happened with another hi-fi system's USB port. However, when powered with a phone charger or by directly applying 5V to the GND and +5V lines of the USB plug, it worked. My first guess was, that those USB ports don't output enough power for the adapter. This was easily disproved by being able to charge my phone over this port. I measured the voltage on the two power lines: 5V. So this should be alright.
Apparently it had something to do with the data lines. I opened the adapter to have a look at those and indeed, they where connected to the bluetooth chip. Maybe for configuration/programming in the factory. It seemed like this is is what pees on the parade. The AV receiver tries to communicate with the adapter and thereby freezes it.
Unsoldering the plug and bending over the data lines to disconnect them is what fixes the problem.

<s> Is that really what the manufacturer expects us to do? </s>

- Marv

Yet Another WS2812 library

I'm currently working with the WS2812 LEDs. They are awesome because they're so simple to hook up and interface with.
Probably the most popular Arduino library for programming these LEDs is FastLED. It features a ton of useful functions and super optimized routines. And you cannot only use LEDs with the WS2811 controller, also SPI based controllers. However, I failed getting it to work with a 8 MHz AVR.  It seemed like the timing was way off.

Edit: It is the ATmega 1284P that will cause problems with FastLED. Apparently the bit-banging-routines are only working on 328, 32u4 and 2560. This is due to the larger memory the 1284P can access, which needs 3 address bytes instead of 2 with the 328. Therefore, jump-instructions take one tick longer. At 8 MHz that is 0,125 µs which is 10% of the period of one bit at 800 kHz (the clock frequency of the WS2812). That's why the actual clock frequency of the AVR needs to be 10% higher than defined in the F_CPU macro. According to this, the developers of FastLED are aware of this issue, but are not going to fix it.

Over at the Arduino forums, someone recommended using a light weight WS2812 library instead. I tried this one and it worked like a charm. Unfortunately, it is so "light" that it doesn't even support a global brightness parameter. Also, the way the HSV to RGB conversion is a bit user-unfriendly by using an indirection with another RGB-struct.

So I changed the whole library by Tim aka cpldcpu, Matthias Riegler, Windell H. Oskay and Freezy a bit up. I added direct RGB and HSV access to each pixel, the optimized HSV to RGB function from FastLED and a global brightness method, which is defeatable by commenting out a single line (to make it lighter for ATtiny). It isn't beautiful, but it works and some of you might be interested in it, so I shared it.
https://github.com/emgoz/WS2812

- Marv