Category Archives: Projects

Installing Replicant 4.2 on Galaxy S1

Yesterday, I decided to install Replicant on a Samsung Galaxy S1 ( i9000, also referred to as galaxysmtd in the builds ). However, it already had some version of Cyanogen Mod on it – apparently, not the one that was installed. Also, I had to blacklist some drivers for heimdall tool to work on my Linux laptop.

When flashing recovery – if you connect a Galaxy S1 in download mode to a Linux laptop, it’ll present itself as a serial port, then the cdc_acm driver will load and, apparently, send some AT commands (to check if the device is a modem), which crashes something in the download mode code, apparently, so it stops responding to the heimdall tool and there’s always this “Protocol initialization failed” message, and if you get further, there are still problems

To solve this, I added two lines: “blacklist cdc_acm” and “blacklist visor” to an /etc/modprobe.d/blacklist.conf file, and then rebooted. I don’t know if that could be solved without rebooting, only after reboot it seemed to be solved for me.

After this, I could easily flash Replicant-provided recovery image to the phone. However, it’d give this error all the time:


“Error in (Status 0)”. Not the most informative error message. Basically, the scripts returns “ran normally” but the install doesn’t continue. I opened the .zip and saw the there, which ought to have been the file causing that error. After debugging the script execution path with some ui_print macros, I found a section in the middle of the script (in the section for “new mtd layouts” or something) that would stop the process, but exit 0 (erroneously assuming something IIRC).  I removed that section, and it went further – but got stuck on some thing that would “exit 7”. I removed that exit statement too, and Replicant finally got installed. TODO: understand what that “exit 7” thing was complaining about.

However, Replicant is running great now, so all is well =)

SSD1332 65K 96×64 Color OLED sample code + pinout + simplest Eagle breakout

So, I’ve searched for this display’s files for two weeks. Those are cheap (3$ on eBay), but unlike all those SSD1332 displays with green ribbon of uniform width (and available drivers and breakouts). I’m not even sure if this display is SSD1332 based, and I’m not sure I care after many frustrating unsuccessful attempts to get it working. It’s cheap, however, but you do get a bare panel with a controller.

Apparently, these displays are produced by RiTDisplay. They weren’t that helpful with datasheets though and it’s not even listed on their page. Also, apparently, it’s discontinued now. The display has 27 pins, with SPI and 8-bit interface both available. I found it listed as RGS10096064FR004 on one site but the datasheet seemed to be behind the paywall.

Recently, I found the datasheet (more or less accessible), pinout information (found it before somewhere too, but it was hard) AND SAMPLE CODE! I haven’t yet checked it, but since it was hard to find, I’m sharing it with others.

Dropbox link

RGHost link

Yandex Disk link

Also, I’m sharing the simple board I’ve made in Eagle. It’s in no way complete –  no annotations, some jumpers might be missing for your purpose and you’ll have to check the pinout for your driving mode, but the FPC pitch is right and all the pins you’d need are broken out on headers. I also plan to transfer it to KiCad quite soon, so expect it to be available as well.




Yandex Disk

Remaking MSR206 RS232 magnetic card reader to USB

As you might have noticed, sometimes I work as freelancer in electronics =) It applies not only to fixing PC electronics and mobile phones, but also to repairing, modifying and designing my own solutions in consumer electronics. One of the projects I worked on yesterday is modifying MSR-206 magnetic card reader to replace RS232 port with USB. Let me tell you about that…


This was of high urgency, so I’ve had to suspend my usual work activities and concentrate on this project yesterday. MSR-206 is a pretty impressive piece of technology, incomparable to those cheap eBay magnetic card readers. It even includes 24V 2.2A DC power supply, which is quite heavy and makes you question those cheap USB 2.5W card readers – like, are they really OK for most applications when somebody released such a powerful thing just to accomplish the same task? It’s also kind of state-of-art inside… Well, maybe it’s just me being used to see a lot of disassembled Chinese stuff =)
Unfortunately, it also is quite old – it has only RS232 port in 8P8C (Ethernet cable) form-factor, not to mention non-standard wiring. My acquaintance working as the IT guy in one hotel had to replace the receptionist PC with a newer one. He didn’t think of need of having a COM port, though. Also, the original COM-8P8C cable was lost, and, of course, cheap COM-8P8C cable for connecting to network equipment didn’t work. So – there’s a hotel that needs their equipment to be in working state ASAP…Which meant replacing RS232 with USB. RS232… I instantly sensed MAX232 chip inside.

So – I disassembled this card reader. Looks great, doesn’t it?


OK, the top part doesn’t mean much to us. Let’s pull out the PCB:


On the left side, you can see something related to a power supply. Logic runs on 5V anyway – so I’m not supposed to look closer and examine =)


L293D? OK, maybe there is a motor or some kind of motor-like thing inside =) Wasn’t exactly my job to figure it out.. 3 of them is something, though. I also didn’t want to see what’s the chip with a sticker on top – must be a MCU, and I knew it didn’t matter to me because I wouldn’t understand it anyway =) Those old MCUs are a PITA when you have to somehow change contents of the ROM or something like that.


Some kind of logic elements… OK, that’s not what I’m searching for. Let’s see the bottom side of PCB.


A lone transistor/regulator… Doesn’t matter much.


Some more logic elements, I guess I’ll have to examine them in case somebody got high and implemented UART-RS232 using buffered logic gates.


Woohoo! The object of my search. As you know, MAX232 has 2 RS232->TTL (R-T) elements and 2 TTL->RS232 (T-R) elements inside. One pair of R-T&T-R is RX and TX. Other pair is usually unused… Usually. Let’s desolder the chip to see what’s actually used…
Sorry, sticker, you just were at the wrong place at the wrong time.
Oh. All 4 elements are used. That’d mean trial and error =( That’s the moment when I realised that I should give Google a try. What I’ve got? A programmer’s manual! Pinouts, commands and so on! Excellent!

First of all, manual doesn’t mention 2 of 4 lines coming from MAX232 to the 8P8C connector. I guess they aren’t that significant then. Other two lines are TX and RX and wiring for MAX232 is exactly the same as on this circuit diagram:

So I soldered 3 wires to GND, TTL RX and TTL TX. What you’d need a chip for then you can interface USB to TTL directly? That’s when a USB-UART converter appears on the stage.
It’s based on ARK3116 chip, which works on Linux and Windows. I guess now it’s time to say – what a shame that Windows drivers aren’t open-source! This chip works with both x32 and x64 Linux versions, but doesn’t work with Windows x64 – exactly the OS that hotel uses. They’ve installed x32 OS on reception, though – PC wasn’t configured yet and it wasn’t that hard. This board is so small because it was inside of a mobile phone interfacing cable.

So – I soldered headers to the cable that carried TTL signals (the one I soldered instead of MA232). First, I’ve tested them using a FTDI breakout board – it was guaranteed to work good. You know, I’vehad some problems with USB-UART converters in the past =) I issued a command that turns all 3 indicator LEDs on the board… It didn’t work. I swapped TX and RX and – voila!

Photo (sorry, not screenshot) of my monitor – programmer’s manual on the left side, cutecom terminal on another:
BTW, Cutecom is a great serial terminal with a GUI =)
Now it’s time for ARK3116 with a USB-B socket soldered to it. That’s when things went wrong – I had wiring problems, soldering problems, adapter problems, software problems and so on. After an hour or so, it finally was OK:

“[ 587.976696] usb 6-2: ark3116: don’t know how to do software flow control

Sorry, converter, neither do I.

It worked… The only problem was that case wouldn’t close. Turned out that I needed to reposition the converter somewhere else. Like this:
Cover with a bit of masking tape:
*puts sunglasses on* Case closed. Now testing with original Windows-only card reading/writing software:
Woohoo! Ready to be given back to the hotel.


One more thing for my portfolio in freelance electronics 😉 That sure was fun to make and I hope that’ll inspire somebody. Now – back to writing software for my Arduino payphone project.
BTW, my part-time job now is software testing. It seems that the job changes me already – I’ve found a bug in Tetris:


tetris-bsd from bsdgames package

Minimizing Eagle-made boards

Disclaimer: I haven’t yet tested any of these projects as currently I haven’t got a possibility to print PCBs even using the toner transfer method. So use them at your own risk – as you should do with any other project on the Internet =)

From time to time I find cool PCB projects on the Web that are just too big for my use or otherwise unsuitable. Sometimes, those are proprietary and you cannot do anything about it. Other times, source files are available and I use my Eagle CAD knowledge and just minimize the PCB dimensions, replacing components and throwing out useless parts =) The power of open-source hardware, hell yeah. Anyway, here are three Eagle CAD projects that I’ve minimized and would like to share.

1) Tiny USB LIRC-compatible receiver

I was searching for a really tiny USB IR receiver for my laptop. I’ve been searching for a long time but it seemed that every solution wasn’t fitting and had one of three problems: 1) not tiny,2) not USB, 3) not for laptops. Finally, I’ve found a solution on this page that is also full of research on the topic… Still not small enough, but the page includes Eagle CAD files! So I’ve got them and opened them, and noticed that connectors could be replaced in favor of smaller ones. (USB-B for MiniUSB) I did that, rearranged the components on the board and it looked nice. That was the first version – the second has 4 holes for wire instead of connector, which makes it even smaller and embeddable – I plan to embed one in my laptop, one in my Raspberry Pi project and keep some assembled receivers in the drawer just for other projects =)

  • First version – photo (some traces are interrupted but it’s OK – you have to use “Ratsnest” tool, so you get a nice ground fill polygon):
  • Initial version – Eagle files are on the same page where I’ve found the circuit
  • Second version – photo (you can compare boards by looking at the FTDI IC):
  • IR receiver
  • Second version – Eagle files

2) FTDI SIM card reader

This is a quite nice thing that Adafruit used to sell as kits for assembly. It included FTDI and RS232 interfacing circuit – I’d call the second part useless in our days, since nobody’d use COM port when there’s FTDI header available. I took the schematics, threw out everything that was related to RS232 and made the board as little as possible. Almost all the remaining components were replaced with their SMD variants, so this board now is as wide as SIM socket and just a little bit longer =) I guess I’ll order 5 PCBs of this after a while – just after I figure out why the heck I’d need them 😉 I’ll definitely have to extend the capabilities of the SIM card reading software that Adafruit provides (I guess it’s not actually made by them, but I’ll find the owner and fork his repository 😉 ).Also, I’ve made an eBay collection with needed parts in bulk, so that when time comes I can easily order everything – and so can everyone.

By the way, before making this board, I’ve assembled a deadbug-style prototype that actually is even smaller and works with USB-FTDI converter without any problems. Here’s a photo for you:

3) 12V-220V power inverter

This Arduino project  by was featured at Hackaday some time ago and I got interested in it, having searched for something like that for a long time. It’s an inverter that takes 12VDC (or whatever here is) and converts it to the 220VAC. It’s controlled by AtMega 168P in DIP package, and there were no SMD components in the original circuit at all. I decided to fix that and asked the author about original .sch and .brd files – fortunately, he shared them. You know, many people just do not share their original files – and I guess that’s one of the biggest mistakes a person can make when designing something that wouldn’t be much of a problem to open-source. See, when all that’s
between a slightly useful project and quite useful project is uploading some files to a hosting, I prefer the latter.
Anyway, I opened those files, replaced through-hole components with SMD and rearranged the elements… I also needed to retrace the whole board, I’d say it was quite challenging =) I don’t know if it works as good as the previous version, though – haven’t tested yet, but you’d definitely need to change some pin assignments in firmware – I mean, LEDs and maybe something else I’ve forgot about, just compare the schematics and you’ll see – I’ll probably do this make a follow-up as soon as I’ll make this board myself. I think I’ll replace temperature sensor with DS18B20, but that’s just an idea.

I’ve already got more minimized projects that I’d like to tell you about, but I guess it will be later – after I check if they’re, in fact, working =)

Project: Payphone remake

One of my current projects in R&D stage is converting a GPT payphone to Arduino platform while preserving all the abilities and keeping its outside as-is. This is a project I’ve started to plan when I was asked to unlock this payphone. See, they have smart card system inside which somehow is responsible for security of the payphone and all that stuff… And the payphone effectively fails to work both with or without a small internal SIM-like smartcard, it’s locked with it and not working without it.
So what? We have a payphone that is useless, even though it’s a masterpiece inside – i’ll show you why.
Without any clue about how to unlock anything on existing hardware, I’ve got an idea… What if I could replace everything that relies on smartcard system (that, unfortunately, means about 75-85% of all electronics in the payphone) with self-developed solution that’d even be upgradeable in terms of its capabilities? That is, we take a MCU, we take all the other parts that we’d need to make a landline-connected phone, put them all together and write the firmware so that they all work together. Great, isn’t it?

When I had to choose a base, I chose Arduino. Why? Development will be easy for me because of great choice of libraries, my knowledge of Processing used in Arduino and huge count of people that are ready to help. Also, there surely are people who might repeat my project, and Arduino would be great for beginners. But… How the hell do you connect Arduino to a landline, let alone make it work as a payphone?

Turns out this isn’t easy, yes. AFAIK, Arduino cannot work with voice, so I’m kind of limited in what capabilities the payphone can have. However, we can leave alone voice synthesis and concentrate on how the heck do those two thin wires that come to our phone make sound…
It’s called DAA interfacing, and I’ve found around 10 articles or posts from people who had it implemented on different platforms. Turns out that you’d have legal problems connecting things to your landline… So – there’s a solution, called DAA interface module, it’s a bit like IC because it has all the needed components in one package, furthermore, it’s FCC approved. It takes those two wires and has contacts to connect the microphone, speaker and some more helpful contacts, such as signalling when there’s an incoming call and when the handset is lifted. Some even have Caller ID contact, although it’s not my case as currently I cannot find any DAA interface which has it and is in stock. Problem is – they’re old and they’re not manufactured anymore. Therefore, stock is not so great as I’d wish it was.
I’ll be ordering two different DAA module ICs:
1) CH1817 – datasheet is here, I’m getting them from here
2) CH1812 – datasheet is here, I’m getting them from here (same seller)

I’ll need to hook up a DTMF decoder to the module’s audio output and a DTMF generator to the module’s input. I’ll also need to mute microphone pre-amp for the time that DTMF generator will make sound. I’ll need something to control keypresses. There are keys on the payphone – and I need to preserve both them and PCB that has all the contacts for keys on it. I plan on cutting traces that lead to keys, disabling them from the rest of the PCB and wiring some kind of keypad controller IC to them. Maxim has one, it has I2C interface and does everything that’s needed – but it’s only QFN, no SOIC package available… There’s a need for a breakout, for sure =)

What about DTMF? Those old codes that phones and, recently, some robots and DIY smart house systems, are using to reliably encode and decode numbers over unreliable and limited phone lines? Well, Holtek seems to be partly targeted at that. They have both DTMF encoder and decoder ICs available, which are easy to control and cheap on eBay. Holtek even has a caller ID decoder IC available, even though I don’t yet know whether I’ll be able to implement that – it has some limitations =( All those ICs are easy to hook up to Arduino, there isn’t much code to be written and they’ll provide all the necessary functions.
By the way, the payphone has a nice HD44780 controlled screen. This screen has a connection header that is fully compatible with all those cheap 16×2 HD44780 screens, all the pins are of this header connected to right pins on HD44780 (I checked with an ohmmeter). In short, differences between this screen and any cheap 2-dollar HD44780 display on eBay are following:
1) Non-standard dimensions – this screen is 1,5 times bigger than all the screens available. Finding another one with the same dmensions would be quite a pain in the ass.
2) It doesn’t freaking work for me yet =(
I’ve ordered replacement controller ICs – there are two of them on a display board. BTW, those are quite hard to find – thank god I’ve found some offers on Alibaba. Well, they were expensive =(
I’ve added a diagram I made in Dia, it explains what’s connected to what =)


What I’ve ordered?

  • DTMF generator – HT9200
  • DTMF decoder – HT9170
  • Two solderless breadboards – for prototyping (already arrived)
  • Replacement controller ICs for the display – HD44780 and HD44100
  • Arduino Pro Mini MCU
  • DAA modules – I’ll be using only one but you can never be sure, things happen to break at the wrong time =)
  • RTC module – using DS1307 chip and the breakout I’ve developed by myself.

I haven’t yet ordered the keypad controller IC, unfortunately. If I won’t have it in time, I’ll make a keypad controller using a spare Arduino Pro Mini =) Here’s my eBay collection for this project – includes almost all the parts I’ve bought.

Some links, projects and articles about DAA interfacing:

  • This is probably the best article. It’s very close to my project and I guess I learned a lot from it. For everybody that will follow the same path as I did, this has to be read through.
  • This article provides a lot of nicely explained theorethical information about designing your own DAA interfaces. I won’t be following this path because DAA module is claimed to be safer, but it was nice to know more about what am I actually doing 😉
  • This is a price list from Cermetek, company that used to produce those DAA modules. Has nice datasheets of ICs that currently can’t be found anywhere 😉
  • This site sells spare parts for GTP Sapphire payphones. Just so you know =)
  • This is a project with handmade DAA interface – a landline-controlled alarm. If you can’t get a DAA module, take a look here – and don’t forget that theorethical article above so that your interface works instead of catching fire!
  • One more dial alarm with DIY DAA interface. This is described much better than the previous one =)
  • Sample project with DTMF generator hooked up to the phone line. Has some info about transformers and stuff.

More photos of this payphone:


That’s how it looks inside. Right part is security+DAA+MCU module, box on the left is a coin counting box, which hides a card reader/keypad/accu charger/display modules.


This module seems to be some kind of safety/power module, unfortunately, when I was doing research on it, I couldn’t connect it to the landline to check. When I’ll be assembling everything, I’ll retrace the schematics and fully understand what it does.


Card reader module. Probably even has some actuators to push the card out – I didn’t look, I just guess.


Some photos of main board (right side). Contains DAA and many, many general-purpose 15-year-old datasheetless MCUs that would be impossible to reverse-engineer. Also contains a DB9 port, must be COM – will see when I’ll work on it.


Security module. So much of a mess because of this PCB and some code in those MCUs that, apparently, says “Nothing will work without a proper authentication on my watch!”



Display, keyboard controller, accumulator controller and all that stuff. 



More about keypad



The display. Why doesn’t authentic HD44780 IC work using the same protocol as all the other displays on this IC use?


Some stickers from inside of the payphone. Google search for “Multipaymond” gives 0 results… Now there will be one =)

Wait for updates – there sure will be some when I’ll get all the parts!




DS1307 real-time clock PCB (SOIC)

I’m back to writing posts! And expect a long post about my Raspberry Pi wearable PC soon =)

Here I present you a tiny I2C RTC powered by DS1307.


  • 5V power
  • Possibility to connect 3V battery to save clock value while power is off
  • Small enough – 3,5×2,5cm
  • All parts are easy to find

IMG_0464 IMG_0466

Here’s the PCB image I made using EagleCAD. It uses:

  • CR2032 holder – can be easily salvaged from an old dead motherboard
  • 32,768KHz quartz resonator – same, usually found on old motherboards
  • 3x 10K SMD resistors – could either be bought or salvaged like two previous parts
  • DS1307Z in SO-8 packaging


This PCB indeed is tiny. The biggest part of it seems to be the battery holder, and I chose this type of holder/battery combination because both of them are easy to find. Also, you can hook up your own battery – there’s a pin for this on the pin header, thus, big holder is not necessary if you’re not using it =) I made this PCB just because I couldn’t find anything like this on the Net. Now it’s your, too, so you just need to print image below on a sheet of A4 paper using 600 dpi and you’ll have it 1:1. Hint: use GIMP for printing images with certain DPI. Should there be questions, I’ll post a guide for doing this =)

Hope this helps you in your numerous electronics projects.

 Just FYI again – it’s 5V. Yes, it will burn the Raspberry Pi unless you use a logic level voltage converter suitable for I2C communications. Later I’ll probably tell you about making one 😉

I’d really like to provide Eagle files, but the truth is – I lost them somewhere. I might have a backup somewhere, though =( As soon as I find it, I’ll put all the files here.

Raspberry Pi wearable PC project – updates, v2

Today, I’ll describe a temporary pinout for my prototype and some more technical details. Raspberry Pi seems to have a lot of useful pins. Still, it’s not enough of them for my goals. For now, I’m not including Arduino and thus I’ll need to suffice from what I currently have. There are some protocols RPi supports by hardware. Some of them, however, are supported only by software, and thus we need to use bit-banging and polling instead of hardware 1-Wire or infrared. This makes me sad and also loads the CPU, which I won’t have much of.

The following pins are populated on a GPIO header every Raspberry Pi has. I’ve managed to find a usage for all of them. I’ve also noted which pins are connected to some kind of hardware inside the CPU that supports this protocol (like SPI/I2C/UART Raspberry Pi CPU has) and which pins will need to be controlled using bit-banging, emulating a protocol by software.

GPIO4 – 1-Wire (SW)
GPIO7 – CS1 (HW)
GPIO8 – CS0 (HW)
GPIO17 – IR-out (SW)
GPIO18 – IR-in (SW)
GPIO22 – DRST (display reset) (SW)
GPIO23 – CSm0 (SW)
GPIO24 – CSm1 (SW)
GPIO25 – CSm2 (SW)
GPIO27 – DD/C (display D/C pin) (SW)

As we know, Rev. 2 boards have 4 more GPIO pins on a separate header, P5. This header also works as I2S connection point, so I think I’ll try to get some kind of cheap I2S audio chip supported by Linux and make a small audio breakout board – maybe 😉

There are some GPIOs that I certainly won’t be using in my project, and those aren’t available on some of the headers yet they control some of the RPi features and thus are tied to some resistors or separate connectors on RPi board, such as RPi audio output or I2C pins on RPi camera connector.

I’ll definitely re-use the following pins:

GPIO6 – LAN_RUN (resets USB hub, connected to pin 12 of SMSC chip)
GPIO40 – PWM-out (audio right channel)
GPIO45 – PWM-out (audio left channel)
I won’t need RPi audio anyway, as the quality is too shitty for me to consider this as an option.

Yet I plan on using RPi camera and I’d like to view activity LED sometimes, so the following pins will stay untouched:

But those connectors certainly won’t be enough, so I’ll need to wait for the Arduino stage of my project =)

Current state of my project after this update

Current state of my project after this update

As I’ll make external “shields”, such as the Nokia 3310 screen shield, I’ll need some external connectors to attach things. I also need them to be waterproof, remember?

BTW, what about the displays? Each of Nokia 3310 displays has the following pins:
RESET (needs to actually be used – we have to send a short pulse to initialise a display before usage, Philips even claims that not doing this can damage the controller)
MOSI (seems to perform the same function as SPI SCLK)
SCLK (seems to perform the same function as SPI SCLK)
D/C (this is needed for the display to distinguish between data and commands being sent. Quite logical for the ease of display controller firmware developers, yet that’ll cause some problems as we will need to extend RPi’s hardware SPI by adding software extensions)
CS (seems to perform the same function as SPI CS, active logic level is low, too)
VOUT (needs to be tied to GND through a capacitor)

As I’ve mentioned, I need CS multiplexer for the displays. Guess what – I’ve already built this, just haven’t had a possibility to check anything. I’ve used 74HC138 IC in SSOP case and a little board that extends SSOP to DIP, then desoldered DIP pins and attached the necessary wires. Raspberry Pi has two CS signals. I’ve decided that one of them will be a CS signal for enabling multiplexer, as it certainly won’t need to work for all the time. Multiplexer I use has 3 inputs and 8 outputs. Thus, I need 1 CS pin (as chip enable pin) and 3 GPIO pins to get 8 CS pins – and, as CS signal state doesn’t need to be changed that often during data transfer, I think I’ll be fine with this. I only will use 3 CS signals now but I guess I’ll occasionally find uses for those 5 left – like, for some of those small RF transmitters =)

Click on the image to see the whole picture, not just a part of it =) Active logic level is low because the same is for SPI CS signal.

This is the pinout of display connector I already have made:
EXT_CON1 pinout:

I guess that looks scary. And I hope that's waterproof enough.

I guess that looks scary. And I hope that’s waterproof enough.

But that’s not the only connector I’ll need. I’ll also need to connect more peripherals, like:

USB flash drives or Arduino through USB-UART connection… why not both, after all?
I2C keypad I’m planning to make
Infrared receiver and transmitter
External display that can be connected to TV-out of Pi.
DS18B20 sensors
SIM card readers
LED flashlight
Hardware interrupts – pins that are used to notify Pi that it’s about to receive/has to fetch some kind of important information that can’t wait, like a keypress from an external keyboard.

So – I managed to get one connector from hard disk drive. This was easy to reuse – though I needed a file and some more tools to minimise the connector so that it could fit in the case.

EXT_CON2 pinout:


This connector will certainly require its own Eagle part =(

This all has been connected, too. Now I just need to think about external shields, and I guess LCD shield will be the first to be made =) Also, the mystery – how to fasten shields to the case? Screws might not be waterproof enough, magnets will have to be strong enough to hold everything and weak enough not to trigger the switches… I’ll have to think about it, for sure. I’m getting my LCDs during this week, hope they’re not buggy and will fit, else everything will be delayed.

For now, I just need to buy DC-DC converters. My search of custom one or two-layer PCBs for easily available DC-DC ICs kind of failed. I realised I have to go for pre-built modules =( I guess it’ll be hard to find one that won’t be bulky and will be efficient at the same time. So – VIN pins on the EXT_CON2 are not yet connected. Also, there’s just the same 5V-3,3V linear regulator =) I’ll certainly have to remove it, too – as soon as I get a pulse DC-DC.

Looks a little bit scary but it's really so little that I couldn't discard it.

Looks a little bit scary but it’s really so little that I couldn’t discard it.

I’ve installed wireless module I’ve desoldered from a broken tablet PC I had lying around. Many of those, especially cheap Chinese craplets, have WiFi modules either soldered on the top of the board or connected by wires. This was the case for me, so this module was easy to get. Just one thing – some of USB devices that are soldered inside other electronics need 3V3 voltage, not 5V. So be careful with them, should you use one. As you can see, I also supply 3V3 to my module using a separate wire =)
My module is identified in lsusb as:

Bus 001 Device 005: ID 0bda:8179 Realtek Semiconductor Corp.

It’s based on RTL8188EUS chip, and Raspbian didn’t have drivers for it in the default distro. That’s when I understood this situation needs a lot of luck. I googled “how to set up network on raspberry pi model a”. See, I basically made a Model A RPi out of my RPi Model B. That means – no Ethernet. It turned out most people didn’t even think about this or even use network on a Model A. Those who did, used USB-WiFi adapter… And mine didn’t work because it didn’t have a driver.

As I obviously needed to install software, I needed network connectivity. One could have tried using PPPD, but it’s not in the default distribution and therefore doesn’t make sense – to set up PPP connection, I needed to install PPPD, and in order to install PPPD I needed network connection. PAN over Bluetooth had the same problem – no Bluetooth support by default =( So the only way to go was USB-WiFi module. Some modules are supported out of the box, but some require a firmware package to work. Downloading a firmware package from repositories has the exact same problem – you need network connection. One can always download a package .deb file, but if there are dependencies or version mismatch, you are screwed. Fortunately, my WiFi adapter didn’t need firmware packages, it only needed a driver, which happened not to have any dependencies =) For those curious where’d I get the
drivers – MrEngman on Raspberry Pi forums has compiled those drivers for Raspbian and published them, helping all those people that have WiFi adapter with the same chipset. Thank you very much, man! Should you arrive in Latvia – I owe you a beer 😉

And for those people that own RPi Model A and need a network connectivity for the initial setup – you have two ways. One is picking an out-of-the-box supported USB-WiFi from THIS LIST. Other is plugging your SD card into Raspberry Pi Model B, installing the packages using cable connection and plugging the card back. You’ve been warned 😉

My shitty soldering job =(

My shitty soldering job =(

I already think about making a more serious PCB. That is – I need to eliminate wiring and glueing modules using hot glue. Instead, all the modules I have have to be soldered to the board which’d hold everything. Also, I plan on using a separate USB hub chip – would be great if I could make a big protoboard both populating all the sockets, such as I2C, SPI etc, and holding USB hub and all the USB-connected modules – WiFi/BT/UART/whatever. I don’t really need separate boards, and if I remade this mess of wires I have now into a single shield board, it all would certainly be more stable and I’d certainly save some space in the case. So – now I just need to put all the components into Eagle CAD (my CAD of choice when it comes to electronics) and make a board… There is a problem, though. I wonder if I’d be able to do two-sided board by myself, as I can’t make vias now, and I’ll certainly need a lot of inter-layer connections. So – need to get to know how does one make vias at home =) I think about drilling small holes in the board where vias need to be, putting thin copper wires inside and soldering those wires to both sides of the board. Seems to be the way, at least.

With the custom board, I’ll certainly need one option: controlling modules’ power supply. That is – putting a transistor in the power line of each module, be it WiFi, screens or external modules. That will save energy and also improve reliability as it’ll be a possibility to turn off a module should it break and short-circuit everything or freeze everything. I can imagine some kind of power-on self-test-now. Let’s say there’s a startup program that checks all the modules, turning them on one by one. As there’s a possibility that a module is faulty and system will freeze, it has to be taken into account. When system freezes, RPi built-in watchdog will automatically reboot
the system. To avoid reboot loop, the program controlling modules will have to see which module failed on each startup and avoid turning it on again until the problem is solved. It could be done by making some kind of flag before launching module and removing it after the module has been sucessfully loaded, and checking for unremoved flags at each boot to determine whether the boot process had been interrupted due to a module failure. Or, maybe, making boot-up logs and parsing a log of previous boot during the boot process. Any way, this seems to be a good idea – I’ll just need hardware and software to support it 😉 Offtopic: it’s always as cruel as this. We might have excellent ideas – the only problem seems to be the implementation, that’s where most of the ideas get crushed.

The card, with WiFi antenna and DS18B20 connectors visible.

The card, with WiFi antenna and DS18B20 connector visible.

I’ve now bought 8GB SD card for my Pi, and it is still alive =) Seems to be indestructible no matter what I do. Now I just need to test whether the CS multiplexer is working or not, set up Bluetooth and WiFi AP software, install some necessary Python modules for the development, then connect one Nokia 3310 screen I already have and start testing. Software will certainly take its time. I can fit various modules into my setup but there’s no sense if I can’t really use them because there’s no program able to control them. God, this will be a challenge =) Now I see the following software problems for me to be solved:

  • Nokia 3310 LCD control. I’ll need to see whether I’ll need to go for LCDProc or just build my own module on top of “spidev”, extending hardware SPI. That’ll be the challenge, especially when you remember that those LCDs will be the main output device for interacting with user.
  • SPI multiplexer control. It will probably be simple yet problems are still possible.
  • I2C keyboard driver. It’s a little bit early to talk about this because it hasn’t been designed yet, so there’ll be a separate article. But there certainly will be problems =(
  • Menu controller. See, in my plans this keyboard will control some kind of menu where one’d be able to select various actions from those that will be available – and there’ll be a lot of actions available =) So this all needs to be coded somehow, and be reliable and fast.
  • Infrared device control. It really depends on what I choose to do, I guess LIRC will do for the most use cases, but I’m still wondering – what if I’ll need more?
  • Audio device control, that is – volume/active device/source/sink control. I’ll probably use Pulseaudio, but one needs to remember it’s far from perfect.

There’s a big possibility I’ve forgotten to include something, I know =) But you also know that I’ll tell you about the problems I meet on my way, sharing my experience with you. So you’ll se by yourself =)

Waiting for the board to be soldered on =)

Waiting for the board to be soldered on =)

Talking about the I2C keyboard, I’ve received two I2C GPIO extender ICs from Maxim Integrated. They’ve been so generous as to provide me two free samples of it =) Now I’m thinking about how to design a I2C keyboard I’m planning to make. Won’t be that simple yet will be simple =) Gotta spend some hours in Eagle CAD preparing for this, I haven’t actually tried to make my own components in Eagle, so it seems that this will be the first one. I’ve already ran into some design difficulties. That is – my keyboard has to be CPU-efficient, generate interrupts only when a key is pressed, not require any CPU work unless there’s a pressed key (those are 3 different things 😉 ), and it also has to be reliable and cheap. However, I already do have some ideas in mind. I guess it’d be fun to ask advice about this project from Maxim technical support =) I guess they do have some good ideas about how to implement it, and will be able to provide the feedback about my implementation.

The next update will be when I’ll feel I have enough to say =) So stay tuned, it won’t be long. Just keep in mind that I also am preparing for the finals now, finishing my high school. That means I won’t be able to spend as much time on this project as I would be able, be it holidays =(