Electronics on Voltaicforge

Multiroom audio with the Raspberry PI

Sun, 24 Jul 2016 00:00:00 +0000

Multiroom Audio with the Raspi

I’ve wanted some sort of audio system for years, a set of speakers in multiple rooms you could setup to be controlled via an app that would be able to play my music collection, and radio. In the past I’ve experimented with just having iTunes on a laptop with speakers solely for it, putting speakers on my server and some other options. None have ever hit the ’neat and tidy’ aspect.

Recently I started playing around with the RasPI squeezebox solution piCorePlayer which was a big step in the right direction I was looking for. Surely I could find a cheap set of speakers that would look neat, but have enough space to squeeze (pun intended) a RasPi inside of?

Off to AliExpress I went and found a cheap(ish) little Bluetooth speaker set. It actually had a decent set of features, pity I would not be using most of them.

Above is the finished player (which looks the same as how it comes out of the box). I managed to fit a RasPI 1 inside of it, wired up to the power and aux input jack. The PI connects wirelessly to my wireless network by a Wifi dongle and runs off the Logitec Media Server software. So via an app or internal website I can play music or radio and media server will kick off the RasPI to play, pause, volume, etc.

It’s truly a poor man’s Sonos.

Hacking the speaker

The speaker is a cheap Bluetooth-capable speaker off AliExpress. It’s got more functionality than I wanted but was the only one I liked the look of that could potentially fit a RasPI. I got it Friday night and quickly tore it down.

I found that it indeed did have enough room to hide a RasPI. But only just, and only after the RasPI has undergone some radical weight reduction. I setup a wifi dongle I had lying around to run on the RasPi and verified it worked before proceeding - I already had Logitec Media Player on a virtual machine running on my server.

I then played around and inspected the circuitry to find where I could hijack power from the speaker power. It had a power input which was just a standard micro USB-B connector, so it would be running +5V which I could just tap the RasPI into. I cut one end of the USB to Micro USB-B connector that came with it and soldered it to GND and the closest point I could tap +5V. I suspect it was a regulator to drop to +3V or so - the lithium battery included only had 3.7V in it so one would suspect the logic to be +3V. I tried pulling direct from the battery charge points but it only gave out 4.7V, which the RasPI flat out refused to boot on.

I did accidently blow a resistor to GND during probing for voltage (which a bodge wire quickly fixed, shorting the plugs housing to another GND point on the board).

Then it was on to the drastic reduction - the RasPi would have to havethe RCA plug, line-out, Ethernet and the USB plugs stripped. I either cut or desoldered these as what was easiest (cut off all but the Ethernet and USB, which required adding fresh solder and then sucking it out). The solder on the RasPI melts a LOT hotter than usual, so adding fresh solder was the trick.

After the rapid weight loss, I had to find a way to get the USB wifi adaptor back on it. I threw any concept of the USB spec out the window and directly connected the USB pins to the WIFI dongle with a ribbon cable.

After everything, it looked a little worse for wear but it worked fine. Then I started probing around to figure out how to connect the Pi’s line out direct to the speaker system.

I bodged wires from the aux input jack of the speaker system to the pi - guessing the left and right channel would be the pins connected to the capacitors I could see on the board. The centre pin turned out, as I suspected, to be ground.

I tested it as it was and it worked. The speakers had some bad line noise (as you’d expect from a cheap set) so I turned them right down and the Pi right up. Once I had done that, it was great!

Afterwards, it was merely a case of fitting the PI into the housing and it fit like it was designed to be there. Some hot glue and a zip tie, and it was time for reassembly.

Once reassembled, it looked like it was new out of the box. All it required was a home to be found for it and for it to be plugged in with any old wall plug & USB Micro B cable. Once it’s powered up, the PI boots up into piCorePlayer, connects to the Wifi, and is ready to receive music or radio streams! Just running the Andriod app Squeeze Ctrl allows me to control the Logitec Medis Server, which finds the RasPi and considered it an output device. A tap of the app and we have music control.

All I need to do is order a few more and I have a Sonos-like experience, for a fraction of the price.

Multiplexing Seven Segment with AVR

Sun, 29 May 2016 00:00:00 +0000

Multiplexing a dual seven segment display

Following on from driving a seven segment with an ATTiny2313a last post I swapped out the single seven segment for a dual seven segment that I bought from AliExpress. This one was a dual display with a similar set of 10-pin inputs like the last, single one. The pins from A-G+DP are different to the last, but more tellingly instead of two anode pins for the single display, there is now an anode pin for each segment. Power one pin with some of the LEDs pulling to ground and one lights up, power the other and the other one lights up. And if you power both, you get both sides displaying the same thing.

I found a post at (codeandlife.com) that helped me out with the timers & interrupts, which again I’ve found harder to find relevant code for:

Here we need to multiplex. What is that? Well, multiplexing is described as:

Telecommunications. of, relating to, or using equipment permitting the simultaneous transmission of two or more trains of signals or messages over a single channel.

In this case, to drive one seven segment we have already used 7 pins + power. If we added another stand alone display, that would become 14. What about building a clock with 4 digits, do we go and get an MCU with 28 or more pins?

Nope. What we do is setup an array of seven segments (two in this proof-of-concept case) which share a common set of lines to drive each LED. But we split the input lines (in this case anode) to the LEDS so we can drive them independent of each other. This enables us to set the AVR pins to sink current to enable one number, and turn the first part of the display on. After a brief delay, we turn that segment off, change the AVR pins for the second number, and turn on the second part of the display.

I’ve measured this rig at between 5-15mA, depending on what is lit up (with a number 8 being the most)

Warning: Keep in mind as well that an ATTiny2313a is rated to 20mA sourcing of current. Exceed that and you might burn it out!

If we do this very fast (I measured the frequency at around 250mhz) the human eye blends together images and we see both sides lit up simultaneously. This is extremely common and you may be surprised to find where this occurs. If you have a DSLR, try taking very short exposures of LED displays!

Wiring up the breadboard

So I rewired the breadboard up similar to last time, but taking into account the different pins. Also, instead of +5 going to one of the anode pins of the seven segment I wired one anode of the seven segment to PD4 and the other to PD5 of the ATTiny2313 - this time the AVR will drive the anodes.

avr-pin	letter	led-pin
PB7	A	pin 10
PB6	B	pin 9
PB5	C	pin 1
PB4	D	pin 4
PB3	E	pin 3
PB2	F	pin 6
PB1	G	pin 5
—	—	—

Schematic

Info: I couldn’t find a common-anode dual seven segment display on octopart - this is a quad display but imagine its only a dual display.

Warning: The pinouts on this dont match above, again because the part isn’t present. If you follow this, check your part datasheet.

PDF Schematic Download

View on CircuitMaker

Code

With the below code, the display counts from 0-99. Brightness is fine, but can be a problem with more displays. AVR is running interal clock with clockdiv/8 fuse set.

Here we use a timer to increment a counter each second. A second timer runs the multiplexing, with ~500 interrupts per second. Thats almost it!

Info: I have started using bit flipping defines for legible code and easy of use. Might annoy the purists!

/*
 * PoorMansSevenSegment.cpp
 *
 * A bodge program to run a seven segment without a BCD - 7 segment display decoder
 *
 * Created: 15/05/2016 6:50:30 PM
 * Author : Nat
 */

#define F_CPU 1000000UL //CPU speed, set clockdiv/8
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

// Defines for  easy bit flipping
#define    bit_set(...)        bit_set_(__VA_ARGS__)
#define    bit_set_(x,y)        x |= 1<<y            // set a bit
#define    bit_clear(...)        bit_clear_(__VA_ARGS__)
#define    bit_clear_(x,y)        x &= ~(1<<y)            // clear a bit
#define    bit_test(...)        bit_test_(__VA_ARGS__)
#define    bit_test_(x,y)        (!!(x & (1<<y)))        // test a bit

/*** following macros related to the PORTx - register only !    ***/
/***                                ***/
#define    bit_dir_outp(...)    bit_dir_outp_(__VA_ARGS__)
#define    bit_dir_outp_(x,y)    *(&x-1) |= 1<<y            // access DDRx of PORTx !
#define    bit_dir_inp(...)    bit_dir_inp_(__VA_ARGS__)
#define    bit_dir_inp_(x,y)    *(&x-1) &= ~(1<<y)        // access DDRx of PORTx !
#define    bit_test_in(...)    bit_test_in_(__VA_ARGS__)
#define    bit_test_in_(x,y)    (!!(*(&x-2) & (1<<y)))        // access PINx of PORTx !

// pin defines
#define PORT_LED PORTB
#define DDR_LED DDRB
#define PORT_PWR PORTD
#define DDR_PWR DDRD

// define Seven segment output ports for Vcc to Seven Segment
#define LED0    PORTD, 4
#define LED1    PORTD, 5

//binary representations of binary required to light seven segment 0-9
unsigned int pins[] = {0b11111100, 0b01100000, 0b11011010,0b11110010, 0b01100110, 0b10110110, 0b10111110, 0b11100000, 0b11111110, 0b11100110};
volatile int i_timer_seconds = 0;
volatile int i_active_display = 0;

void seven_write(int i_digit) {
    // write to entire LED port - invert due to the fact that in a common anode display LOW = on.
    // to use in a common cathode display, remove inversion.
    PORT_LED =~ pins[i_digit];
}

ISR(TIMER1_COMPA_vect) {
    // increment timer count
    i_timer_seconds++;
}

ISR(TIMER0_OVF_vect) {
    PORT_PWR &= ~(1 << (i_active_display+4));    // turn off LED
        //toggle active display
    i_active_display ^= 1;

    if(i_active_display == 0) {
        seven_write(i_timer_seconds % 10);
    } else {
		seven_write(i_timer_seconds / 10 % 10);
    }

    PORT_PWR |= (1 << (i_active_display+4));    // turn on LED
}

int main(void)
{
    //disable interupts
    cli();

    //Data Direction Register, set all bits high
    DDR_LED = 0xFF;                // enable entire LED port as output

    // set led common anode wires to outputs (PD4/5)
    bit_dir_outp(LED0);
    bit_dir_outp(LED1);

    // init timer 0
    TIMSK |= (1 << TOIE0);  // timer 0 overflow interupt
    TCCR1B |= (1 << WGM12);  // config for CTC mode
    TIMSK |= (1 << OCIE1A);  // CTC interupt
    OCR1A |= 15625;             // prescaler
    sei();
    TCCR0B |= (1 << CS01); //timer 0 at clk/8
    TCCR1B |= (1 << CS11)+(1 << CS10); //timer 1 at clk/64

    while (1) {}
    return 1;
}

Poor man's seven segment LED display with AVR

Sun, 15 May 2016 00:00:00 +0000

Driving a seven segment display with no BCD to seven segment chip

I have gotten a batch of cheap seven segments from DealExtreme, and it was high time I put them through their paces.

However, I have no BCD to seven segment chips. No matter, I can bodge it up just using 7 pins. So I ran through some code to just drive each segment with a pin from an ATTiny2313a.

I found from the data-sheet for the 7-seg LED that it was a common anode. So that means I had to drive LOW to sink current to light LEDs - and keep HIGH to keep segments off.

Starting off by working out the seven segment display and working out in a table which logic levels for each led; to drive the segments for numbers 0-9. I’m sure it was searchable online, but where’s the fun in that?

Using my new target board to hook up the 2313a to a breadboard - with 330Ω from each LED. I saw from the datasheet for the LED seven segment that it had common anode on pins 3 & 8. Using the pinout below I was able to breadboard connections. It was a simple case of matching up PB0-PB7 to match up with the led segments from the datasheet, via the letters.

I hooked up PB0 through PB7 to the seven segment display, using the pinouts above to correlate to the pinouts I drew out. I did get tripped up on the direction here - thinking that PB0 was the highest bit in the register! Of course, it isn’t!

So I ended up with:

avr-pin	letter	led-pin
PB7	A	pin 7
PB6	B	pin 6
PB5	C	pin 4
PB4	D	pin 2
PB3	E	pin 1
PB2	F	pin 9
PB1	G	pin 10
—	—	—

Info: Pin 0 is not connected! When I added the binary to the code I added a trailing 0 to the binary to bump it up to 8-bit.

Schematic

PDF Schematic Download

View on CircuitMaker

Code

/*
 * PoorMansSevenSegment.cpp
 *
 * A bodge program to run a seven segment without a BCD - 7 segment display decoder
 *
 * Created: 15/05/2016 6:50:30 PM
 * Author : Nat
 */

#define F_CPU 8000000UL //CPU speed, remove clockdiv/8
#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    //binary representations of binary required to light seven segment 0-9
    int pins[] = {0b11111100, 0b01100000, 0b11011010,0b11110010, 0b01100110, 0b10110110, 0b10111110, 0b11100000, 0b11111110, 0b11100110};
    int count = 0;

    DDRB=255; //Data Direction Register, set all bits high

    while (1)
    {
        for(count=0; count<10; count++) {
            //change output of entire portb register to above hex (inverted, as its common anode and LED on requires sinking current.
            PORTB=~pins[count];
            _delay_ms(1000);
        }
    }
    return 1;
}

End result

Error with device 0x000102 whilst programming AVR

Sat, 14 May 2016 00:00:00 +0000

Device is read correctly the first time but fails to be read on subsequent reads

I’m building an AVR target board for a few different flavours of AVR to make my life easier.

I had some real fun trying to read the data-sheet pins back to front whilst soldering down the sockets, and had to have more than one go at getting the ATMega328P socket wired up correctly.

I was using Atmel Studio 7 to read the device ID of various AVR chips I had on my board. When suddenly it would work on the initial read after power up - but subsequent reads would fail with the device ID being returned reading 0x000102

Reset line short to ground stopping reset line returning to high post-programming

I had introduced a short on the reset line to ground when fixing my wiring. This was causing the reset pin to be low regardless of what the programmer did.

This makes sense - the initial read works OK as the reset line is LOW. But the AVR chip never leaves programming mode until reset returns to HIGH. This is the reason we add pullups to the reset line.

With the reset pullup being forced LOW all the time, the AVR never leaves programming mode, and a second programming attempt fails as the AVR is not reset back to the start of its programming phase.

First AVR LED blinky

Thu, 05 May 2016 00:00:00 +0000

Testing out new AVR Gear

Well, I’ve received the new programmers I ordered. Amongst them was the Atmel ICE, which I have chosen to be the first thing I would test.

I’ve been meaning to get fully into MCU development, but I have to say that the Arduino craze didn’t really grab me. A sketch? Shield? Buy pre-assembled gear and push it together, copy and paste code?

Pass. I prefer to code, learning and assembling circuitry myself and learning code from examples.

I’m actually struggling a bit to find decent tutorials for MCU programming (I can’t be looking in the right places). However, it wasn’t too hard to figure out the pinout of the Atmel-ICE and compare to the pinout of the ATtiny 2313A using the data-sheets. I build a miniature shield that plugged in over the top of the MCU and had a neat little 6-pin plugin header (I may cover it in another post).

Info: The Atmel-ICE data-sheet nicely doesn’t include the direction of the tab in the user guide. The pinout on the user guide doesn’t include the tab on the 6-pin connector. I have added it to the data-sheet image below - the tabbed connector is on the side of MISO, SCK and RESET (for SPI programming)

So after plugging in the programmer I confirmed all was well in Atmel Studio 7. Tools -> Device programming gets you to the device programming screen, and selecting Atmel-ICE tool and your chosen device (in my case I had the ATTiny 2313A, so I selected ATtiny2313a from the device selection). The interface is ISP and you can click Apply.

Once this has been selected, you should be able to click on Read for the device signature. If it reads an address and target voltage, you have succeeded.

I proceeded to load up a blinky led program to confirm all was well, and well, all was well.

Out of curiosity, I was interested to know the maximum frequency this would have out of the box on the output pins with no _delay_ms(), with its default 1Mhz clock cycle (8Mhz internal oscillator with the CKDIV8 fuse clocking it down to 1MHz)

Whilst I did leave it with two I/O operations per cycle, I did come up with a frequency of 103khz.

Nexus 6P Pocket Dial woes

Tue, 03 May 2016 00:00:00 +0000

Nexus 6P keeps pocket dialing

I love my Nexus 6P. It’s a fantastic android phone and easily the best phone I’ve ever owned (despite the almost excellent experience with my Samsung Galaxy S4). The Nexus 6P is perfect for someone who wants a non-bloated OS/ROM but also still excellent hardware.

Also, the phone is encouraging me to be social. Like, calling my friends from my pocket whilst there at work. Sorry, Crossy.

I’ve been scratching my head and finally found out the root settings that were causing the pocket dialing.

Fixing pocket dialing

Finally figured out the pocket dialing settings that were causing me the woes. Many people complain about ambient display waking up the phone in your pocket, and then from there the phone getting random touches from your leg and thus pocket dialing.

In my case, that wasn’t actually the whole story. My issue was actually the Tap to wake being set to on. This setting wakes the device if it detects a double-tap on the screen whilst it’s off. So yeah, pocket dial city - I don’t remember my S4 being this touchy-feely on the screen.

Ensure both are off and you should be fine.

Unfortunately, Ambient Display has been pretty poor on Andriod so far. It should be quite good - but I’ve found it difficult to use effectively. It is quite difficult to move it enough if it’s just sitting on your desk to activate ambient. I’t seemed to display every time you didn’t care about it - and none of the times it did.

Time (and patches) will tell if this feature is built into anything as good as Moto Display.

W.E.P 853d clone soldering station

Mon, 25 Apr 2016 00:00:00 +0000

Time for an upgrade, from cheap solder pen to cheap solder station.

After living with an old non-temperature controlled soldering iron for years I decided it was time to upgrade. I had been using a Goot PX232 for a long time, and before that some Jaycar $15 iron that was only just passable as a soldering iron.

Now, despite the fact I should be getting a decent brand, I decided to try a cheap eBay clone. I found a ‘W.E.P 853D Soldering Station/Hot Air Gun/DC Power supply’ on eBay, within Australia. Few days later I have it in my grubby hands.

I’ve been perfectly happy with the operation. I’ve had it now for a few months with no issues.

The soldering iron has tips that fit over the cartridge, it heats up quite nicely. It comes with a large variety of tips (conical, chisel, wedge) and sizes. The iron holder is pretty lousy and the tip will hit the rear of the case and lean against it. I’ve continued to use my old iron holder due to this. Its such a relief to be using decent bits now after struggling along with conical for so long.

The iron heats up to 300° C within 47 seconds, so on that side it’s not so great, unfortunately.

The hot-air gun comes with a few tips to have wider/smaller airflow.

The power supply I only used a little, but it was accurate to its displayed measurements. I haven’t had much experience at measuring power supply ripple so will skip that for now, but I can’t say I’ve noticed or seen much ripple on my oscilloscope.

Teardown

Finally, that’s out of the way. I had to have a look see inside - would it be complete cheap Shenzhen market garbage? Or would it be somewhat passable. More importantly, was it a Yihua station with a different name like I suspected?

Presentation was quite nice. My preference is the black and gold to the gaudy blue and yellow others have. Buttons have a nice tactile feel to them and knobs are firmly stuck on and feel OK considering. LCD is clear and bright.

I won’t profess to be any good at a teardown, but the transformer seemed OK, earthed down to chassis with decent connectors. Power transistor is well secured (housed on the rear of the chassis). I know people have concerns about cheap Chinese equipment such as this being a fire hazard - but I didn’t see anything that concerned me. I’ve seen worse build quality from gear built in better countries and companies that was worse.

PCB in the middle of the board hosts some TRIACS, bridge rectifier, MMOC3041 optocouplers, and various passives. Caps are no name (Jwco) garbage, but at least the TRIACS have heat sinks. A single LM723 voltage regular sits on the board. Soldering seemed perfectly fine, looks wave soldered (or at least reflowed)

The control panel has two S3F94C4EZZ MCU’s and two LED display drivers (TM1620 & TM1628). Can’t determine the manufacture for the MCU’s, I get either a Samsung or Zilog part - I’ll leave you to guess which I think is the more likely manufacturer. Not much else happening there, soldering continues to look fine. I can’t see any post-production fixes or anything untoward dodgy - if I had been given the photos to look at without knowing where it came from it would look visually OK to me.

Wait a minute here - the control PCB has a silk-screen designator of ‘YH852DV5A’. Clearly the same control board as the Yihua model. After some googling I found an EEVBlog post regarding the Yihua which showed a photo with an identical control board, but what to me looked like a significantly worse power board.

Meanwhile, whilst I wait to see if Shenzhen lets me down again I will continue to enjoy my nifty little soldering station.

LCD Haul

Fri, 22 Apr 2016 00:00:00 +0000

Workplace preps to throw out 300+ phone units

We’ve upgraded our phone system for the entire business at work. When I piled the old Ericsson desk phone into the box they had set up to return the old phones the thought hit me - there’s a lot of speakers in the 300 odd phones that are being thrown out. Wait, forget that - I bet this LCD is generic.

So I took a few home and tore them down - and what do you know, but the LCD is a HD44780 based. I politely informed the IT dept they no longer needed an external contractor the throw them out, I would take them, thank you.

I wanted to ensure I could get it working before grabbing them all. While I am yet to receive the MCU programming kits I’ve ordered, so I found an old Arduino Mega I had lying around from the 3D printer build. Whilst this should have been a simple check, Murphy, of course, got me - the ribbon cable pin pitch width was just too small for me to solder on my own ribbon cable to break out onto a breadboard. I had a few goes but the two sizes of ribbon cable I had on hand were the right width and bending the pins to neatly marry up with the solder pads just wasn’t working for me.

Getting a salvaged 10 pin HD447800 LCD working

My solution to break it out was to slice up the individual wires from one of the actual ribbon cables from the phone and solder it to a 12 pin header. The challenge here was that most HD4480’s are 16-pin - and this puppy had a 12 pin input. I did notice that 2 pins weren’t apparently connected by a quick scan of the PCB, and assuming it was actually a 10 pin LCD some googling revealed the following pinout.

1: Gnd
2: VCC (5v)
3: Contrast (10k pot)
4: RS
5: R/W
6: E
7: DB4
8: DB5
9: DB6
10: DB7

And the header of the Arduino Liquidcrystal library includes where to connect the pins of the Arduino to the LCD.

 * LCD RS pin to digital pin 12
 * LCD Enable pin to digital pin 11
 * LCD D4 pin to digital pin 5
 * LCD D5 pin to digital pin 4
 * LCD D6 pin to digital pin 3
 * LCD D7 pin to digital pin 2
 * LCD R/W pin to ground
 * 10K resistor:
 * ends to +5V and ground
 * wiper to LCD VO pin (pin 3)

From there it’s easy enough to connect the dots. So no backlight, but a perfectly working 2x20 LCD.