Solar Eclipse April 8th, 2024

 

I had become aware in 2017 that our place of domicile, Norfolk County, Ontario would be in the path of totality for the solar eclipse of April 8th, 2024. So I was hoping to live long enough to see that day...

 And, indeed, I did make it. My preparations for viewing the eclipse started a few weeks before the big event. Of course, clear weather is very important for a proper eclipse experience, so as soon as the first weather forecasts were available, (10 days) I started monitoring them. Sunny weather is by no means guaranteed here in early April, so I kept a close eye on various forecasts from different sources. As the day got closer, they all seemed to say something different, e.g. Niagara will be fine, but points further west might be cloudy. Others said it will just be high, whispy clouds, still other predicted sunshine. Who to believe?

Meanwhile, I did the usual YouTube search and viewing of various videos pertaining to other people's experiences during previous eclipses, with a specific interest toward the photography aspect of things. Initially, I had just thought of projecting the sun's image on a piece of white paper using binoculars, as I had done during the partial eclipses of 2012 (in California) and 2017 (here at home). I soon came to the realization, however, that during a total eclipse, that was not going to work, as the corona probably would not be strong enough to be visible using that method. So I started thinking about using my DSLR with zoom telephoto lens to directly photograph the sun's corona during the full eclipse.

 

I wasn't too interested in the partial portion of the eclipse, as I had seen this quite a few times before (snob that I am). But, in order to be ready to photograph the full eclipse, I needed to have my camera already aimed at the sun. Having the camera look directly at even a reduced portion of the sun's surface is a very bad idea (burnt out sensor could be the result), so I created a filter out of some cut up eclipse glasses and a roll of packing tape. The shape of the roll fit snugly over the telephoto lens and was easy to remove once the eclipse had started.

I had also decided to remotely control my camera from my laptop using a USB cable. For software I used the Canon EOS Utility. The user interface on the laptop is much easier to use than the controls on the camera themselves. Plus cranking your neck through a viewfinder in dark conditions does not sound like fun.  

I had looked up the exact times of when the eclipse was to occur here. It was to start at 3:16:53 and last for 2 minutes and 39.5 seconds. I wrote a small application in Visual FoxPro that announced various important times relating to the eclipse, e.g. "Full eclipse will start in 5 minutes". This application made sure that I would be well prepared for the start and end of the eclipse.

I had also decided to put my second DSLR on a tripod in the backyard to film the entire event. I synchronized the times of cameras to the current date and time.I also synchronized the time used by my laptop with that of the internet.

On the eventful day, I woke up and immediately ask Google "OK Google, what's the weather going to be like." I couldn't help but laugh when she replied "Rainy with a high of 16".  However, looking on the Environment Canada website's image of clouds over our area, I noticed, yes it was cloudy, but this band of clouds stretching from north west to south east was slowly moving northeasterly, with Windsor, Ontario already being in sunshine. So, with a bit of luck, we would be in sunshine by early afternoon...

When returning home from getting some groceries, I noticed quite a stream of cars westbound on Hwy 3, probably coming from Niagara Falls area, trying to find the sunshine. And yes, the sun came out around 1:00 and things looked perfect. Nephew Chris Peake phoned from Toronto, asking how things were here, I told him in all likelyhood we'd be fine, so he decided to come down. At about the same time, Wendy, Greg and their kids Brock, Amaryn and Marek arrived.

At 2:05 there was the first sighting of the moon encroaching on the sun's territory: the partial eclipse portion was starting. We all got out our eclipse glasses and had a look. Nephew Chris arrived at around 2:45. Next, I  set up the tripods in a good spot with full view, mounted the cameras, put a table with my laptop next to the main camera, tethered them, aimed the camera (with filter) at the sun, started the timing application. General laughter ensued when it immediately announced all important times in very quick succession. Oops, software glitch, quickly fixed. I then started the camera filming in the back yard.

As the eclipse became more prominent, it got darker and darker, with the sunlight becoming a kind of grey. However, I was unprepared for how quickly the light level dropped off from 99% eclipse to 100%. Literally within 30 seconds in became dark as night. I had to make a switch on the camera from 'Program' to 'Manual' and for a very brief moment, panic struck me, as I didn't know whether I would be able to see it in the dark. Fortunately, I was able to so, in quick succession I shot images of the corona, keeping aperture at f8 and ISO at 100, but successively stepping down the speed starting at 1/1000th, down to 1/100th.

Following that I decided just to enjoy the spectacle, as someone had advised on YouTube. And a spectacle it was. Standing in the middle of the backyard, in the middle of the day with the sky as black as ink. You could clearly see planet Jupiter to the left of the sun and Venus off to the right. I didn't notice too much about the animal life, except for the mosquitoes: they came out immediately and started to bite us!

 Soon it was over and the light coming back was equally impressive as it was fading beforehand. My granddaughter had made a little video of the fading light when the full eclipse set in, which was most illustrating.

To celebrate the event, we immediately broke out the beer and toasted one another to our good fortune of having been able to watch such a spectacular event in our lifetime. In sunshine, nonetheless. At the time of the full eclipse, Niagara Falls was still clouded over.

The backyard eclipse video was a success as well, although I did some adjustments, brightening it up and raising the sound level in Photoshop. When viewing it, I discovered the planet Venus was visible as well.

My corona effort:
 

 

My granddaughter Amaryn's light dropoff video:

 

 

The backyard video (available on YouTube)

 

Coupling a home made microphone to Bluetooth

I stumbled across a tweet a few months ago from @helenleigh who was doing/had done a presentation at Hackaday's Remoticon, showing the world how to make your own microphone using mostly materials found around the home. This got me really intrigued, since I have an affinity for using articles out of the realm of their original intent.

So I watched the video on YouTube Remoticon 2020 // Finding Sound and Making Microphones Workshop and then went to work acquiring the supplies. Our local dollar store proved instrumental in supplying the quilting hoop and hair bands. I could have used ones we already had at home, but I do want to get along with the rest of the family. We did have enough binder clips, I also had a spare USB cable, as a matter of fact, I probably have a box full of them, but then again, who doesn't?

So I got to work and built the mic, using a slightly different method than Helen. Instead of rubber bands, I used hair bands, no need to tie knots. Also, rather than plastic, I used the inner circle cut out of an aluminum pie plate. Plus the aforementioned USB cable (which is shielded to prevent the leads from picking up hum.)

The only real electronic components are 2 piezo pickups, which I got from Amazon (in a pack of multiples).

I didn't have an amp of any sort to plug it into, and connecting the output from the mic straight to a set of headphones barely produced any output, so I hunted around for a preamp circuit. I found this:https://samtechpro.blogspot.com/2013/12/dynamic-mic-pre-amplifier.html

I simply doubled up on the circuit to make it stereo (ya gotta be professional about these things), prototyped it on a breadboard, it worked, so I got to transferring it to KiCad (version 5.1.8) 

Not being too familar with KiCad, it took me a lot longer than I anticipated, but here is the design seen from the bottom and then from the top: 

 

 

Next, I undertook the usual routine of creating my own PCB, always fraught we difficulties aplenty. In the end though, I ended up with a nice looking print and PCB.

I mounted the components and decided that the output would go to a 3.5mm jack. The 5V power would come to the board via a micro USB jack. Next, I installed all this in a small box. Finally, I hooked it up to a very small set of speakers and it worked.

Not being satisfied with that, I decided to try and employ a set of Bluetooth transmitters and receivers. Not having any idea if it would work, I tried to get the two to pair, and surprise, surprise, they did. The transmitter is an Aigital Bluetooth transmitter, the receiver is SZMDLX transmitter/receiver combo, the latter being used by me obviously only in receive mode.

I hooked up the mic to the input of my preamp, the output to the Bluetooth transmitter. Then the Bluetooth receiver was plugged into the 3.5mm AUX jack on my computer. Upon insertion, a MaxxAudioPro screen popped up, asking me what sort of device I was plugging in. I chose Microphone in. Then over to Control Panel, Hardware and Sound, Manage Audio Devices, Recording, Jack Mic, then choose Properties and place a tick mark in the Listen checkbox. And voila, I heard my own voice!

This way I can record as well. I must say, the sound quality is pretty decent. Here is a sample:

Additionally, some photographs of how it all looks:

Microphone front above, microphone back below.

The complete setup. For microphone stand, I used a slightly modified cell phone holder, bought at the dollar store for a couple of bucks. Plus, of course, a binder clip.

From left to right, battery pack, preamp in a case, Bluetooth transmitter, Bluetooth receiver, laptop. The circuit board on the top is a prototype of the final result.

Circuit Chaser: Raspberry Pi + NFC = timer for children's run thru a playground.

Circuit Chaser uses a Raspberry Pi along with an NFC reader to clock outgoing and incoming times for cards (or wristbands in this case) being placed near it.

Hardware wise, it consists of 3 major components:

• Raspberry Pi (from the B+ on up)
• PN 532 NFC/RFID controller breakout board from Adafruit
• HDMIPi screen 

Software wise, the main components are:

• Python application using NFC.py to track card touches
• Python application using CherryPy to supply latest info to web browser display
• Web page running in Epiphany browser using some heavy duty JavaScripting to update screen continuously
• Python application monitoring usage and enabling/disabling screen when required

 And then, of course, there is the case, which is actually a case within a case. But more about that later.

This project got started when my daughter bought Zoom Zoom's, an indoor children's playground. Always looking to get an edge up on the competition, we brainstormed several ideas around until the idea of Circuit Chaser came to the fore. This device lets kids clock out, run through a previously determined course in the playground and then clock back in. Runs can be done simultaneously, i.e. more than 1 kid can be out on course at the same time (up to 11).

I covered the installation of the NFC reader on the Pi here: http://khekker.blogspot.ca/2014/01/raspberry-pi-clean-install-of-nfcpy.html.

As a card is brought near the reader, it triggers the reader into action. It reports the unique id of the card, and my Python application then records this in a SQLite3 database table. If a card currently is 'out', the application records the new time as 'in' (or finish, if you like). Otherwise, it records this as 'out', along with the time of the event. The application next does a retrieval of the last 11 records and creates a text file, which will be used by the CherryPy based application described below.

The application also retrieves the pseudonym of the card, making it more palatable for human eyes.

The application based on CherryPy continuously monitors this text file for changes. If found, it will send this file to any browser currently connected to it. If none are found, it goes to sleep for .25 seconds and repeats.

Along with the file sent to the browser is a variable containing the number of seconds expired since midnight, since this is important to keep the times shown on the display accurate. Each system does not necessarily have the same time as the next.

An insight as to how the browser gets to display this information I provided here: http://khekker.blogspot.ca/2013/12/raspberry-pi-cherrypy-and-asynchronous.html

Once received by the browser, the JavaScript takes over and runs continuously, every second updating times for every card/wristband line shown on the display. It uses the variable containing seconds since midnight sent from the CherryPy application and compares it to its own, and either adds or subtracts the difference.

Lastly, the application monitoring usage runs continuously and shuts down the display if no activity has been detected in the last half hour and turns it back on when a card is entered near the reader. The shutting off and starting up is based on this hack by Alex Eames for the HDMPi.

The normal screen blanking on the Pi has been disabled, as explained here:http://khekker.blogspot.ca/2015/12/screen-blanking-raspberry-pi-b.html

I spent an inordinate amount of time on the case. I knew I wanted a transparent case. First, I found a lexan case on the web, which I spent alot of time hacking so the Pi and all its connectors would fit. It looked really good. Then I realized, hey, this has to be used with kids, they can break 'pretty near' (Canadian for 'almost') anything. So I built yet another lexan case around it. Next time, I'll simply go to the specialty place where they sell lexan sheets and for not too much money they can build me a case. A couple of aluminum strips attached to the back of the case allow for attaching to a wall.

The device has been running for over three months now, and has been received well. Better still, it hasn't been broken, hardware nor software wise. It is connected wirelessly to ZoomZooms LAN, and its output could, if port forwarding was employed, be visible on the greater Interweb.

 All files are up on Github: https://github.com/khekker/CircuitChaser, with the exception of NFC.py and CherryPy, as explained above.

The NFC wristbands I obtained from Overair.ca

Raspberry Pi Zero + HD44780 in a slim package for use as fuel computer

Back in August 2013, I blogged about the fact that I had constructed a car fuel computer. In a nutshell, this device displays instantaneous fuel consumption (last 3 seconds), as well as the trip average, using any one of 4 output formats on a dashboard mounted LCD. The device is hooked up thru a USB port to an ELM327 Car scanner, which, in turn, is plugged into the car's OBDII port.

Creation of the device was based on earlier work done by Martin O'Hanlon. It used a Nokia 5110 LCD to display the output. One might argue that it was more of a prototype than anything else, since the display was held to the dash with electrical tape and a case of any sort was absent. Proof of concept.

In doing further testing with the Nokia display, my findings were that it was somewhat unreliable in the harsh environment that a car interior can present. For 'no good reason', the display at times would blank. Reboot the Pi, and everything would be fine again. Not good when you are travelling down the freeway at 100 km/h. (I'll never admit to speeding).

So in early 2014, I adapted the fuel computer application to use the very standard HD44780 LCD (16 characters by 2 lines) display. This time, I used a display case, but it only contained the LCD, since the Raspberry Pi 2 was too big to fit inside.

Enter the Raspberry Pi Zero and its small form factor. Just as soon as it was released November 2015, I knew that I would like to take a crack at incorporating this little miracle along with the LCD in the display box. So, early February, I started on this quest. Of course, what seemed simple from the outset, turned out to be quite the opposite: never have I stared so hard for so long at so few square inches, trying to fit it all in and still have it work reliably as well as allowing for maintenance and accessibility. Here is the result, with the device showing data for the last 3 seconds and the trip average in litres per 100 km (Canadian standard):

This is what you see when you take the 4 screws out of the back and open up the case. Note that the SD card can still be removed without taking anything else out.

For reasons explained below, I had to create an intermediate board between the Zero and the LCD. Here, the HD44780 is on its back here ready for mating with my sandwich board:

And here is the Raspberry Pi Zero and the sandwich board. Notice that only 1 row of GPIO pins from the Raspi Zero are being used.

This is a side view, the HD44780 LCD display on top and the Raspberry Pi Zero on the bottom:

The three buttons perform the following actions: pressing the top one steps thru the brightness level from 1 to 10. Pressing the middle one steps thru the contrast level from 1 to 10. Pressing the bottom one changes the readout mode from litres per 100km to miles per gallon US, then to miles per gallon Imperial, and lastly to km per litre. In addition, if the device detects the car is idling and you press this button, it will change the display to "Press shutdown again within 3 sec". If you do, the Raspberry Pi will shutdown, which is far better than simply turning the ignition key off right away.

So, to construct this, at first I thought I'll just connect individual wires from the Pi to the HD44780, plus a few more to the buttons for contrast, backlighting and display mode and then simply (and cleverly I thought) use short right OTG cables for power and data. Wrong, wrong and wrong. Loose wires tend to break if wiggled once too often or pushed into too tight a corner too vigorously. Too many wires, and you don't know what is what anymore. Besides, what length should they be? And 2 right angle OTG cables won't fit, because one overlaps the other, which makes it physically impossible for it to fit in the intended USB port.

Plan B: use male and female headers soldered directly onto an intermediate PCB (a 'sandwich' board) from both the Pi and the HD44780, then have the PCB traces hook up to the correct pins. In theory, this should work. The total depth of the case is 25 mm, a male and female combination makes up 10 mm, you have 2 of those, what could possibly go wrong? A whole lot, that is.

First off, my soldering skills are level amateur. This means heaps of solder at the base of a pin amounting to probably a few mm. Then you have the thickness of an extra PCB. There are also a few capacitors sticking out of the sandwich board.

Plan C: use right angles male and female headers. After an overnight deliver from buyapi.ca (thanks guys!), I was able to start development of a PCB in Fritzing. I had to get out my micrometer for super accurate measurements. After 12 iterations, (each time I would print a version on paper and fit the connectors on there, trying desperately not to prick my fingers too often) I decided to make a PCB. I will spare you the details, suffice to say, it took a lot of time and it wasn't half bad. Physically fitting it all together seemed to work so...

With loads of confidence, I fired it up in the car and, of course, it didn't work. It turned out, I had soldered and desoldered the HD44780 so often, I had fried it. Fortunately, I had another one at hand.
After soldering on the right angled header, another trial run. More problems. At that point, I realized I still had a database in my possession from the Raspberry Pi 2 prototype. (The Fuel Miser generates a new SQLite database every time it is run.) Since in-car testing is very time consuming and difficult, I decided to create an emulation mode where the Python 2.7 script steps through entries in the database and presents them on the LCD display as though we are driving in a car. Not perfect, but a lot quicker. This weeded out yet another pile of bugs. Next, I also incorporated in the application for info that is normally written to the console to be redirected to a text file. Very handy. This allowed me to, upon return from a trip, to review debug data I had 'print'ed. Finally, success.

But: the case wasn't put together yet and this proved impossible to do without screws through the three boards keeping it altogether. Since I had made no provision in my sandwich board for mounting screws (duh!), it was back to PCB design. A few more hours (or was it days?) in Fritzing, moving components around, making room for the screw heads, and, more importantly, the nuts. I was ready. But, by that time, I just wasn't up to making yet another PCB board myself. Instead, I sent it off to a fab house.

Waiting, waiting, waiting was the name of the game for the next 28 days. That's how long it took to get the board back. Then, soldering it all together and fitting it into the box. Time to test: it works!

I just had to do some software fine tuning. I may still have to do some more.

I used GPIO Zero to use PWM for both the brightness and the contrast levels. You can actually use RPi.GPIO in the same script as GPIO Zero. Who knew! In testing, I found that GPIO Zero was not as fast as RPi.GPIO when displaying text, so I decided to use RPi.GPIO for that.

I also incorporated the writing of text and that of the PWM for the contrast and brightness buttons into a separate class called HD44780.py. Even though I am using the whole unit for fuel economy purposes, as such it could easily be employed for some other use. Another right angle header could be mounted on the Pi, giving access to 20 more GPIO pins.

I kept the readout mode button out of this class, since it is not necessarily related to the functions of the LCD panel.

All the files are on github here: https://github.com/khekker/Raspi-Fuel-Miser. There you will also find a not-so-neat hand drawn wiring diagram. Sorry 'bout that, my Fritzing skills are limited. Check out the readme.md file for further information.

The PCB's from the fab house turned out really nice. I have some spares, in case anyone is at all interested. I'll sell them for $3.00 Canadian plus postage. Let me know in the comments.

Since the following parts are hard to get, I could supply them as well:

7 pieces 2.6 mm screws 10 mm long with nuts $1.00
7 standoffs (3 short and 4 long pieces) $0.50
3 pairs of right angle headers (male and female) (2x6 and 1x20) $1.50
1 project case $5.00

That's $11.00 Canadian, approximately $8.75 US or €7.30 plus postage.

If you want me to 'hack' the appropriate holes in this case, then there is a $5.00 charge for that. Canadian of course, $3.90 US, or  €3.30.

Just 2 observations I made using the device in-car, both of which would likely make safety experts cringe. The first is that driving behind a large truck makes a difference in fuel consumption (around 10%), the second is that on a car with standard transmission ('stick shift'), putting your foot on the clutch while coasting down the hill cuts (the already greatly reduced) fuel consumption in half. But it is not safe to do, so I strongly advise against it.

Note that the device stores a whole range of parameters generated by the engine's computer in a database, which could be reviewed or otherwise analyzed afterwards. For every trip, a new database table is created in SQLite3.

Now if only the Raspberry Pi was more readily available!  Oh, wait a minute...hot off the press...a new Raspberry Pi Zero released today...it adds a camera function. The camera connector sticks out a few mm from the Pi, but that should not present any problems fitting it into this particular case.

How to configure ITEAD PN532 NFC Module on Raspberry Pi

The other day I received the Itead PN532 NFC module in the mail. Time to install it on Raspberry Pi.

The PN532 allows for Near Field Communications, e,g, for using an access card to enter a building or transferring info from a smart phone to a computer.

The installation instructions that came with the device were rather vague or shall I say non existent. And so was any other information about it on the Interweb. Piecing together various snippets allowed me to install it and actually have it work. That is why I am documenting it here just in case someone else comes across the same problem.

In am installing it on Raspberry Pi 2, with Raspbian Jessie as the OS. Furthermore, I will be using it with NFC.py, a Python library I am quite familiar with. It uses the UART set up (serial).

First off, we will not use the double row of pins (26 pins) on the PN532. We will use the single row of 8 pins, of which only 4 will actually be connected to the Pi. Note that you will have to flip the device over to read the markings for each pin on the back of the PN532.

The connection from the Pi to the PN532 is as follows:

Connect Pin 2 (5V) on the Pi to the Pin marked 5V on the PN532
Connect Pin 6 (Ground) on the Pi to the Pin marked GND on the PN532
Connect Pin 8 (GPIO14) (UART TX) on the Pi to the Pin marked NSS/RCL/RX on the PN532
Connect Pin 10 (GPIO15) (UART RX) on the Pi to the Pin marked MO/SDA/TX on the PN532

So much for the hardware side. Now we go on to the software side. Of course, we bring the entire system up to the latest value by issuing:

sudo apt-get update
sudo apt-get upgrade


Then, we need to modify the file /boot/cmdline.txt. Do that by issuing the following command:

sudo nano /boot/cmdline.txt
 
Within this file, change the line

dwc_otg.lpm_enable=0 console=tty1 console=serial0,115200

 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

to this:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 

elevator=deadline fsck.repair=yes rootwait

Next, if you are running Raspbian Jessie on a Pi 3, add this to the bottom of /boot/config.txt file:

dtoverlay=pi3-miniuart-bt

This will disable Bluetooth, but allow the PN532 to work.

Reboot the Pi, and install NFC.py by  issuing the following commands:

sudo apt-get install python-dev 

curl -O http://python-distribute.org/distribute_setup.py 

sudo python distribute_setup.py 

curl -O https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py 

sudo python get-pip.py 

sudo pip install virtualenv

The above 6 commands install (fairly) standard Python utilities. They may be present on your machine already.

sudo pip install pyserial

This line will install serial library for Python used by NFC.py.

sudo apt-get install bzr

This command will install Launchpad bazaar, a VCS (Version Control System), which allows you to download NFC.py.

mkdir pythonprogs 
cd pythonprogs

Above 2 commands create and then switch to the directory where my Python programs will be stored on this machine. You may already have a favourite directory on your machine.

bzr branch lp:nfcpy

This line downloads the latest version of NFC.py.

cd /pythonprogs/nfcpy/examples

Now you've changed to the examples directory of NFC.py.

python tagtool.py --device tty:AMA0:pn53x show

Run the Python program tagtool. The ‘device’ switch following tagtool.py specifies that we want to use the serial device. If there is no error message, things should be working!

Touch a card on the reader. You should get a response on your screen. Notice that you cannot use a Mifare Classic 1K card, they are incompatible with NFC.py. However, I've had good luck with NTAG203 cards, which are readily available.

Raspberry Pi Zero: How to first access it headlessly

I obtained a Raspberry Pi Zero a few weeks ago, but hadn't really done anything with it. I was puzzled as to how to access it initially, since it only has one USB port and no RJ45 connector built in for accessing a network.

The easiest thing would be to get a USB hub, but I wanted a minimalist approach. No screen, keyboard, mouse. This method only requires a wireless dongle. So I did some sleuthing on the old Interweb and stumbled and David Maitland's blog.

My approach varies slightly from his, that is why I describe it here:

get access to Raspberry Pi Zero on the network by:
  - downloading Raspbian Jessie and dump the image on a microSD card using your PC
  - taking another Raspberry Pi, a B+, inserting the 'Zero' microSD card in it
  - hooking this up to the network (or screen, keyboard and mouse)
  - booting the Pi B+
  - modifying the file /etc/network/interfaces file
       specifically: add 'auto wlan0' as a separate line above 'allow-hotplug wlan0'
  - modifying the file /etc/wpa_supplicant/wpa_supplicant.conf
       specifically: add to the end of this file

     network={
     ssid="MYNETWORKNAME"
     psk="MYNETWORKPASSWORD"
     proto=RSN
     key_mgmt=WPA-PSK
     pairwise=CCMP
     auth_alg=OPEN
     }

         Obviously you will replace MYNETWORKNAME and MYNETWORKPASSWORD with your specific values.

  - gracefully shut down the B+
  - take the microSD card from the B+ and insert it into the Zero
  - attach a wireless dongle to the Zero's USB port
  - boot the Zero, it should work. If not, check the entries you made for the network values.

Raspberry Pi how to show less info at bootup

You can substantially decrease the amount of info scrolling by on the screen at bootup time by adding the word 'quiet' (without quotes) to the end of the first line of the file /boot/cmdline.txt

Raspberry Pi Custom Splash Screen (blank screen problem)

I followed the instructions found at http://www.edv-huber.com/index.php/problemloesungen/15-custom-splash-screen-for-raspberry-pi-raspbian for a customized splash screen on the Pi. Everything went well, except….at the end of the boot sequence, the splash screen disappeared and all I was left with was a blank screen. I found out (by trying) that I could type the userid and password blindly, followed by startx (also blindly) and then LXDE would appear as normal.

Hunting around on the forums, I found a post that stated that if you were presented with a blank screen after booting, you should try pressing Ctrl+Alt+F2 to get back to a regular console screen. It worked. I hunted around some more for a better solution, but to no avail.

By the way, this problem does not occur if you have it setup so that you automatically startup startx after booting.