It has been over a year, and what a year it has been. Fortunately I don’t have to go into any of that here.

The TV project has all but died. I still have the spare PCB kicking about, but I’ve not got the motivation to fix my BusPirate probes and try to add USB to my TV. The Rasperry Pi2 is out now, and I don’t think my TV could supply enough current regardless. So one rainy day I might look into this again, but for now – everyone plays guitar, right?

As this post is going to deal with the guitar pedal project I think we should go over some history.

The MP-01 design was released 6th July 2013 (wow, that was a long time ago). It used a single PIC32 with external SPI DAC and ADC. Due to quite a lack of foresight, the rotary encoders were not on change notification pins, and any rail noise was put straight onto the guitar signal. That was a major issue that resigned this version to the junk pile, and the less said about this the better.

MP-02 was to be the savour. The design for that was released almost 1 year ago to the day (tomorrow in fact). I learnt my lessons from the first design. The op-amp stage was re-architected to utilise the op-amps supply noise rejection capabilities. I’d been hit by scope creep quite severely by now. I had moved to a 2-PIC solution; a PIC24 to handle the non audio functionality (which went from just LEDs to include an external port for an expression pedal and USB to allow direct loading of patches from a PC), and a dsPIC33 to handle the real-time audio activities (using it’s in-built ADC and DAC along with the rotary encoders, footpedal switch and EEPROM). After building the pedal I had real difficulties getting the thing to work as I expected it to. For some reason I just couldn’t sample quickly enough and there was still far too much noise. I finally fixed the sampling issue by changing how I was clocking everything, and I was having a pedal that was actually passing the guitar signal through, albeit with a lot of white noise on top. This noise was causing me some heartache as I just couldn’t pin down what was causing it; poor layout, inherent ADC and DAC noise issues, op-amp selection, dodgy power supply. I was fighting against so much that I decided that enough was enough. Plus I blew up the dsPIC twice as apparently the metal enclosure is made of metal.

MP-02 v1.1 was to be the savour! I refused to play any more games. The dsPIC range do have inbuilt ADCs and DACs but they just can’t compete against a proper chip. So I enlisted the help of something made for audio; the Wolfson WM8731. This blows the 10 and 12 bit capabilities of the dsPIC out of the water with a whopping 24bits at 192kHz. It supports pass through of the audio without requiring it to even enter the dsPIC. We have volume control, anti-thump mute, and filters coming out of our ears. This is definitely going to go some way to helping the sound. The LMV321 op-amps are out. I looked over the specs and the limited slew rate is fighting against us. I am looking at a couple of different op-amps to use instead, and I am favouring the LMV793. A slew rate of 24V/us (instead of 1V/us), and a noise density of 6.2nV/rt(Hz) (instead of 46 nV/rt(Hz)) means that this pedal will be singing. I’ve added some external SPI SRAM into the mix too. At 512Kb we have enough storage for over 5 seconds of audio (16bit mono 48kHz). This doesn’t sound a lot but it is more than enough for a decent echo. Plus unlike EEPROM, SRAM can be written to again and again and again… I’ve still got the EEPROM though, boosted to 512Kb too. This allows me to bootload both the PIC24 and dsPI33 from SPI or UART without having to support the entire USB stack in the bootloader. Scope creep got me again, and now we support USB OTG. This means that whilst you can plug the pedal into a PC to download new patches, you can download from your phone instead or use that as an expression pedal, or simply plug in a USB memory stick to load patches directly. This just opens up the possibilities. Finally I’ve added filtering and protection. I probably could’ve added extra but it will hopefully that will be enough.

These changes complicated the design no end, but I still managed to get everything on two layers (this may be the problem, we shall have to see), within my 50x100mm outline, and mostly single sided population. I want this pedal to be silent, as well as whisper, sing, and scream. I’ve done all I can to help with this task from additional components to filter the noise to segregation to help keep any noise where it can do no harm. I’ve even gone to a dedicated audio chip. This marks the beginning of the end of my attempt to design a guitar pedal. All will be revealed in a week or two when the new design gets posted through the door.

I have been fairly lax in updating this website, but hopefully the next post will bring good news.

This post I am going to be demonstrating how to read an I2C device using a BusPirate. The BusPirate is a brilliant little tool that provides a command line interface to various communication buses. I am using the BusPirate V4, but the theory will be the same for the V3 and V3.5. The first device I am going to try and read is the ST24LC21. This ST part is a 1Kbit EEPROM that stored the TV’s VGA information that allows a PC to detect the capabilities of the display.

Attach your probes as follows: Vcc -> +5, GND -> GND, SCL -> CLK, SDA -> MOSI, WP -> AUX. Connect to the BusPirate using your favourite terminal program, and type the following “m 4 1 3” to enter I2C mode. Next enable the power “P”, connect the pull-ups “e”, and enable the pull-ups “W”. Next you can search for any devices on the bus “(1)”. This should show a device on 0xA0 and 0xA1. This is the same device, but the write and read address. To read the data from the chip we set up the address “[0xA0 0]”, and send 128 read commands “[0xA1 r:128]”. Actually deciphering the numbers means delving into the EDID specification (or at least the Wikipedia article), but with that it is possible to determine manufacturing details of the TV, and its capabilities.
For example, byte7-8 (counting on from byte0) contain a compressed ASCII string. 0x58B3 is 0b0101100010110011, which in this scheme turns into 0bx 10110 00101 10011, or 22 5 19, or VES. Microsoft are responsible for allocating these values, and checking here reveals that the owner of VES is indeed Vestel Elektronik Sanayi ve Ticaret, the manufacturers of the control panel. Looking further on, byte17 (counting from byte0) is the year of manufacture minus 1990. In this instance the value is 0x0A, or 10 in decimal. This puts the manufacture year at 2000. I was expecting a much later year, but maybe the EEPROM image hasn’t been updated over all these years.

That’s enough for today, especially as I managed to break one of my BusPirate probe leads. Next time I will be looking through the main NVM chip to see if there is anything recognisable that I can modify. Wish me luck.

I have three problems that I need to tackle; USB, 3x HDMI ports, HDMI-CEC. So again, lets head to the service manual to avoid embarrassment.

There are footprints for 2 USB connectors. Even though I don’t want to plug a memory stick in, it did pique my interest as to the differences. The top-most connector (CN125) is labelled DIGITAL_USB, as opposed to the plain USB of the bottom connector (CN112). Neither of the connectors have a direct connection to the 5V_VCC rail, but instead go through an IC labelled STMP2161. On my spare PCB this part is missing (as I expected), and I couldn’t find a datasheet or anywhere to get one from. Thankfully, the part has both pins and nets labelled, so it isn’t too difficult to at least identify the function of the part, allowing a suitable replacement to be found. The device features ENABLE and FAULT pins, of which the FAULT pin is connected to a net labelled USB_OCD. This device is probably a current limited load switch (OCD being short for Over Current Detected).

Tests have shown the Raspberry Pi has a maximum current consumption of between 500-600mA. This is just a guess, but I doubt that the STMP2161could handle 600mA, so if anything I am lucky that I have to source my own current limited load switch. Failing that I could bypass the switch circuitry and use a resettable fuse instead.

Back to the differences between the two connectors. the DIGITAL_USB goes to a CT216T-R – the Cheertek Integrated DVB-T Receiver. Given this device has digital video and audio decoding capabilities, it is likely that the DIGITAL_USB connection would be used for playing video from a memory stick.

The plain USB connector goes to the MST6WB7GQ-3 – the main MSTAR microcontroller. This is the brains that bring everything together. I couldn’t find any other information about the MSTAR processor, or its USB capabilities. The service manual makes reference to an “Analog USB” port which I didn’t even think was possible.

Enabling the power for the DIGITAL_USB connector is easy, but I wonder how much work would be involved in getting the actual USB data side to work. I am going on the presumption that all MSTAR microprocessors go out the same, and it is just a configuration page in external EEPROM that enables the features. This idea explains a number of things found in the Service Menu (found by pressing 4725 whilst in the TV’s menu). Firstly, there are options for “Digital USB Hotplug”, “CEC Enable”, HDMI3, HDMI4 but they are all greyed out. Secondly, there is the ability to modify NVM (non-volatile memory) data. I think that modifying the correct byte in NVM will enable the greyed out features.

Before I modify the NVM, it makes sense to make a backup. But first I need to find the NVM. Hunting for NVM on the schematic leads to a net labelled SCL_NVM. This is an I2C clock line for the NVM device, in this case a Microchip’s 24C32. Admittedly, I’m getting a bit ahead of ourselves, but it is obvious how the building blocks all come together and what started as a horrifically complicated design is getting simpler.

Back to the USB, and there is another unidentified device – a AZ099-04S. I am guessing this is probably something to help with ESD – maybe an array of bi-directional transient voltage suppressor (TVS) diode clamps. The last interesting part of the schematic is “Impedance 90R olacak”. USB is a differentially driven bus with a characteristic impedance of 90 ohms, and olacak is Turkish for “it will happen”. As to why there are Turkish instructions of the schematic, Vestel is a Turkish firm.

Jobs before the next post are dump the contents of any EEPROM on the board. This includes the main NVM EEPROM (U103) that hopefully enables features, and the VGA EEPROM (U112) responsible for identifying the TV as a PC monitor and presumably including EDID (Extended Display Indification Data). Additionally, the HDMI switch contains an EDID table that should be visible over I2C. There are two I2C flash chips; one on the MPEG decoder (U114), and one on the main microcontroller (U132), that can also be read.