Power Monitoring with the Moteino -- Attempt #2

This weekend at the Milwaukee Makerspace, I continued trying to get my Moteinos to communicate to each other.  I want to get a node to send its power level to the host.  I performed a number of tests and eventually accomplished the goal.

Basic TxRx Test

First, I numbered the Moteinos 1, 2, and 3.  Each Moteino was setup at a frequency of 915mhz.  The high power setting for the RFM69HW was set on all Moteinos.  For the first test, I opened the serial terminal window in the Arduino IDE on each Moteino so I could see the messages it was sending.  For the other tests, the terminal was only on the Receiver.

The test involved uploading the TxRxBlinky sketch on each Moteino -- one as the Receiver, and one as the Sender.  I hooked a button up to the Sender.  Once both Moteinos were powered up, I pushed the button on the Sender.  This caused the LED on the Receiver to change state -- on to off or off to on.  The Receiver also sends some text to the serial monitor.

SENDER	RECEIVER	RESULTS
M3	M2	Passed
M3	M1	Passed
M1	M2	Passed
M1	M3	Passed
M2	M1	Passed
M2	M3	Passed

All tests passed.  All Moteinos can both send and receive.  Also, they all operate with either the USB as a power source or the Lithium 6v battery as the power source.

Gateway / Node Test

For the next test, I used the Gateway / Node sketches from LowPowerLab.  The Gateway sketch was loaded on the Receiver Moteino and the Node sketch was loaded on the Sender Moteino.  All Moteinos were set at 915mhz frequency.  The high power setting was set on all Moteinos.

Before testing a pair of Moteinos, I loaded the Node sketch on one Moteino and watched what happened with the serial monitor.  The Moteino outputted exactly what it was supposed to.

Next, I uploaded the Gateway sketch to a Moteino and started testing.

Test	Gateway	Node	Results
1	M1	M2	Passed
2	M3	M2	Passed
3	M3	M1	Passed
4	M2	M1	Passed
5	M1	M3	Passed
6	M2	M3	Passed

All tests passed.

Custom Node Test

Now that I know all of Moteinos can talk to each other, I tested a custom node program.  It is set to transmit at 915mhz.  The high power setting for the RFM69HW is set.

The custom program is a modified version of the Node sketch from LowPowerLab.  The sketch reads the voltage from the Moteino and transmits it to the host.  (More information about the code to read the voltage is in this post.)

I had the same problem with the sketch that I had last week.  If the Node program tries to read the voltage using the readVCC function, then tries to use the radio.sendWithRetry function, the Moteino appears to reboot--it is re-running the setup function.  If I comment out the line that calls readVCC, the rest of the code processes normally.  However, the send line prints the message indicating it failed.  

After a lot of testing, I realized that the failure message I am getting is always there -- even with the code that comes with the Moteino.  I ran my Node program and the Host displayed the voltage from the Node.  The code works even though the failure message prints.  I don't know if there is something wrong with the code or if I don't understand how the read.send function is supposed to work.

I don't know why the Moteino was rebooting.  I did fix that problem by starting over with the original Node program and adding my code bit by bit.  The problem did not re-occur.  Maybe I had some invisible characters in the code.

Finally, I tested the voltage that is read by the node.  I connected a variable power supply to the power input on the Node.  This let me vary the input voltage.  I started at 6 volts and slowly turned the voltage down.  Sending any voltage over 3.2 registers as 3349 millivolts.  Once the voltage was turned down to 3.2 volts, the device read 3205 or 3196 millivolts.  When the input got down to 3.1 volts, the node stopped transmitting.  So, I will be able to use this code to monitor my battery's voltage.

One of the next steps is to understand how the node and host communicate.

• Can the node sleep until the host calls it?  
• If the node sends data to the host, will it get lost?  Is there a way to know for sure?
• How do we make the device truly low-power?
• What does the Ack do?

Another step is to connect the host to a Raspberry Pi and have the Pi read the serial inputs.

RPI serial console: http://elinux.org/RPi_Serial_Connection

+Moteino
#Moteino

Possible Smoked Moteino

As I mentioned in my last post, I inadvertently plugged power into the GND pin on one of my brand new Moteinos.  There was a small puff of smoke and I quickly unplugged the power.  However, I had a bad feeling that I just ruined my $20 device.

I tested the Moteino to see if anything still worked.  First, I plugged in the FTDI adapter and used a USB cable to connect the Moteino to my PC.  The Arduino IDE software saw the board.  I uploaded the "Fade" example sketch to the Moteino.  It worked.

Next, I loaded the TxRxBlinky example sketch for the Moteino.  I was able to use the Moteino as a Sender device.  I assume that means that the transceiver is also working.

Finally, I used a multimeter to check the voltages.  The Lithium battery I had hooked up was sending 6.27 volts to the Moteino VIN pin.  The 3.3 pin on the Moteino was putting out 3.31 volts.  This means that the regulator in the Moteino is also working.

I think everything is working.  I'm going to try using this Moteino as the main receiver on my Home Environmental Sensor Array.

+Moteino
+Microcontroller
+Arduino
#Moteino, #Microcontroller, #Arduino

Testing Moteinos

This blog post is covering my last two weeks of activity on the Moteinos for my Home Environmental Sensor Array.  Topics include

1. Power supply experiments
2. Attaching a power supply to a Moteino node
3. Testing multiple Moteinos

Power Supply Experiments
I spent a good deal of time trying different ways to power the Moteino.  I was hoping that I could use a 3v Lithium battery as a power source.  That way, I could have an easily replaceable and cheap power source.  However, the coin cell battery I used did not appear to provide enough power to run the Moteino.

Next, I tried a 3.6v Lithium battery that I found in the battery box at the Makerspace.  It put out about 3.6 volts on its own.  After connecting it to the Moteino, I used a multimeter to see how many volts were going into the Moteino.  It registered at about 1.4 volts.  Not sure what is happening but this battery does not provide enough power for the Moteino either.

Finally, I tried using a 6v lantern battery as a power input.  That worked better.  When I tested the voltage with a multimeter, it registered 6.23 volts.  After I connected the battery to the Moteino, I tested the voltage by putting the test leads on the GND and VIN pins on the Moteino.  It registered 6.17 volts.  Since the Moteino has a built-in power regulator that limits the voltage to 3.3 volts, this is more than enough power.

In order to power nodes, the Moteino needs a power source that delivers between 5-9 volts.  The two options are a 6v Lithium battery or a 9v NiCd battery.  I would prefer the smaller battery because it will waste less energy when the Moteino converts the voltage to 3.3 volts.

Attaching a Power Supply to a Moteino Node
Now that I know how much power I need to supply, the next task is to figure out how to attach power to a Moteino that will operate as a stand-alone node.

I bought a 6v Lithium battery as an external power source.  It is just a bit bigger than a 9v battery.  Also, the power ports are recessed.  This makes it difficult to attach wiring to the battery.

My first idea for a reliable power storage solution for the 6v battery was to re-use an existing 9v battery container.  I found an old clock radio on the hack rack at the Milwaukee Makerspace.  The radio had a space for a 9v battery built-in to one part of the plastic case.  I cut out the 9v battery compartment from the case.

I settled on the idea of using screw heads to connect to the recessed battery terminals.  First, I cut a small piece of balsa wood to fit into the bottom of the compartment.  The wood is just a bit smaller than the compartment.  The wood is just big enough to not move around.  Also, when the battery is inserted into the compartment, it will keep the wood from moving.

Next, I put two screws through the wood and cut off the extra length of each screw with the metal bandsaw.  Finally, I attached wires to each screw.  In hindsight, I should have put the aluminum strips on the top of the wood.  That would have helped the conductivity of the wires to the screws.

Putting the battery into the compartment so it has good contact with the screws is a bit tricky since I can't really see what is going on.  However, once the battery is in properly, it delivers 6v.  I can connect the wire leads either to a prototype board or to input pins on a circuit board.  Although this does work, it is not an ideal solution.  Ideally, I would like a solution that works as easily as traditional battery connectors.  Either I could rig up a cap like 9v batteries have or I need a more cozy container that is a better fit for the lithium battery and makes a good connection every time a battery is inserted.  Maybe I could 3D print a container.

Also, I was testing the battery with one of my Moteinos and I inadvertently attached the positive wire to the GND pin on the Moteino.  The Moteino started smoking.  I immediately pulled out the wire but I don't know what damage was done.  When I connect the Moteino to my computer with the FTDI cable, it powers up.  The Arduino IDE client sees the device.  I uploaded a sketch to the Moteino that made an LED blink.  I still need to test the RF device.  If that works, the Moteino may not have been damaged at all.  That would be a blessing.

Testing Multiple Moteinos
I purchased two more Moteinos -- one for my first node, and one for backup or the second node.  The

Moteino site has a section on programming the Moteino.  One of the Arduino sketches allows you to test a receiver / sender pair of Moteinos.  When you press a button connected to the sender Moteino, it sends a signal to the receiver that toggles an LED -- if it is off, it turns on, and vice-versa.

I was able to successfully test this with two of the Moteinos.  Now, I know a bit more about using the Moteinos.  Next, I need to figure out how to connect the receiver Moteino to my Raspberry Pi.  Another next step is to write a sketch to read something on the node and send it to the receiver Moteino.

Power monitoring with the Moteino -- Attempt #1

This week, in my regular time at the Makerspace, I experimented with the Moteino I recently purchased.  I want to use the Moteino as a temperature sensor in my Home Environmental Sensor Array (HESA).  One thing I would like the sensor to do is measure the voltage coming from the battery and report it back to the host.  This way, I will know when a battery on one of the sensors is about to die.

The Moteino is fully compatible with an Arduino UNO.  Vishal from the 'space told me that the Arduino has the ability to determine the incoming power.  There is an internal reference voltage that always measures 1.1v.  This reference voltage can be used to more accurately measure the input voltage to the Arduino.  Here is a web page that talks about this in more detail.  That web page also has code to measure the input voltage.  Below is the code that I used to measure the voltage on my Moteino.  The output consistently read 3369 millivolts.

long readVCC() {  // Read 1.1V reference against AVcc  // set the reference to Vcc and the measurement to the internal 1.1V reference  #if defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)    ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);  #elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)    ADMUX = _BV(MUX5) | _BV(MUX0);  #elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)    ADMUX = _BV(MUX3) | _BV(MUX2);  #else    ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);  #endif     delay(2); // Wait for Vref to settle  ADCSRA |= _BV(ADSC); // Start conversion  while (bit_is_set(ADCSRA,ADSC)); // measuring   uint8_t low  = ADCL; // must read ADCL first - it then locks ADCH    uint8_t high = ADCH; // unlocks both   long result = (high<<8) | low;   result = 1125300L / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000  return result; // Vcc in millivolts}
void setup() {  // initialize serial communication at 9600 bits per second:  Serial.begin(9600);}
void loop() {  float voltage = readVCC();  // print out the value you read:  Serial.println(voltage);  }

BTW, after uploading the program to the Arduino, I opened the serial monitor by clicking on Tools, Serial Monitor.  The serial monitor displays the output from the Arduino.

Next, I wanted to see what the voltage would be from an external power source, as opposed to the Moteino getting power over the USB cable.  I connected 3.5v power from an adjustable power supply to the VIN pin on the Moteino.  The voltage displayed by the program never changes from 3369 millivolts.  I am not sure if that is because the Moteino was still taking power from the USB or if the built-in power regulator works with any power input.  

I plugged my Arduino Uno into the USB port on the computer and uploaded the script.  It consistently reported 5068 millivolts.  Adding 3.5v power from the external power supply on VIN did not change the readings.

I need to figure out how to get the Arduino or Moteino to send data back to my computer or maybe to a Raspberry Pi without using a USB cable.

Started Working on Moteino Wireless Sensor Node

The Home Environmental Sensor Array is basically where I want it to be at this point.  It will:

• detect water leaks and turns on a backup pump if water is found;
• measure temperature and humidity in my basement;
• write data to a SQL database on the internet;
• send emails if it detects problems and send an "all clear" message when problems clear

The one thing I would like to do before moving on is have it record data locally if the internet is down and write it to the database after the internet connection is restored.

HESA Phase 2

However, I would also like to start on to the next phase of the project.  Originally, I thought that would mean adding an LCD screen and blinking lights as well as more sensors connected to the Raspberry Pi or Beaglebone Black.  But as my Maker skills have grown, I have gotten more ambitious.  Now, I would like to build wireless sensor nodes that connect back to the RPi base.  The nodes would collect data for things like temperature in rooms around my house and outside, monitor the freezer in the basement, etc.  Ideally, I will have a true network of sensors all around my house.  

Moteino Introduction

To get started on the wireless network, I purchased a Moteino. A Moteino is "a low cost low-power open-source wireless Arduino UNO development platform clone" that also has a HopeRF RFM69 transceiver.  My initial idea is to make a stand-alone sensor using the Moteino and a DHT22 temperature sensor.  Since the Moteino is an Arduino UNO clone, I can write a script to have it record the temperature in a specific location and send the results wirelessly back to my Raspberry Pi every few minutes.  (More about that later.)

The Moteino is made by LowPowerLab.  They also sell the Moteino and many other parts.  I bought one Moteino to start with along with the flash memory add-on, some header pins, and an external FTDI adapter so I can connect the Moteino to my PC with a USB cable.  (I suppose I could have made my own FTDI cable.  I researched making one and it seems too hard.  Now that I have the adapter, I can use it with any Moteino that I buy in the future.)  The Moteino comes with a strip of wire cut to the right length to serve as an antenna.  Finally, I also bought an extra HopeRF RFM69 transceiver that I would like to connect to my RPi.  (More on that later.)

Assembling the Moteino
I was at the Milwaukee Makerspace and used the awesome resources at the 'space to assemble the Moteino.  There is not much assembly required.  Basically, I just soldered the header pins to the board.  I am not sure if there is a side of the Moteino that is the top but I chose the side with the RF69 transceiver as the bottom.  This means that the pins that will plug into the breadboard or circuit board are on the transceiver side of the board.  I put the side pins for the FTDI adapter through the holes from the top of the board.

I put solder flux on the holes where the solder would go.  Flux is said to make the solder flow better.  One thing that makes soldering header pins easier is to put the pins into a breadboard and then set the board on top of the pins.  The pins are straight and will not move while I am soldering.  Soldering the pins is pretty easy.  I heat up the pin for a few seconds then touch the solder to the iron.  The solder naturally seems to flow around the pin.  Just make sure the hole around the pin is completely filled.  One caution is: heating the pin for too long might damage the board or the breadboard.

After soldering all of the connections, I used a multimeter to test for shorts.  I set the multimeter to test for resistance.  Then, I put one lead on one pin, and the other lead on the pin next to it.  If the pins are connected by bad soldering, the resistance would go to zero.  I did not find any shorts.  Huzzah!

The picture below shows the FTDI adapter from LowPowerLab connected to the Moteino.  The adapter makes it easy to connect a PC to the Moteino.  The Arduino IDE application sees the Moteino as an Arduino Uno.

Moteino Software
The LowPowerLab website has a lot of good information about the Moteino.  The guy who made the Moteino also has Arduino programming libraries on Github.  The website has good information that I will not repeat here.

One thing I had to do was put the Arduino files in the proper place.  I use a Linux laptop as my Maker device.  So, my Arduino sketches are in the /home/kbecker/sketchbook folder.  I moved the Moteino sketch folders into the libraries folder in the sketchbook folder.  One thing I learned is that it does not matter what the name of the sketch folder is as long as it is in the libraries folder.  I renamed the sketch folders so they start with "Moteino_".  I was able to compile one of the RFM69 sketches.

Next Steps
In order to test the Moteino, I need another RFM69 transceiver.  I did buy an RFM69 with the intention of connecting it to my Raspberry Pi.  However, I can't find much support for that on the internet.  So, I will have to figure it out myself.  Physically connecting the hardware will probably not be that hard.  The difficult part will be writing the software for the Pi to connect to the transceiver.

Another idea in the short-run would be to connect the RFM69 to an Arduino Uno.  Then, I can use the Moteino sketches on both the base and the node just to make sure it works.

Finally, I would like to design a board for the node.  The board would include the Moteino, a coin battery holder for power, connections for the sensor (DHT22 on the first one), and (if I can figure it out), a circuit to measure the power level of the battery.

I'll keep posting as I make progress.  I'll also add a new project on my Makerspace wiki page.

Electric Razor Fixed

We have a Remington Precision electric razor that my wife uses to cut the kid's hair.  The other day it started acting up.  Wiggling the wire would make it turn on or off.  Obviously, there was a break in the wire.

I was at the Milwaukee Makerspace tonight and brought the razor to repair.  It took me about an hour to do the work but I think I fixed it.

There is only one screw holding the case together.  After removing the screw, the case comes apart with a bit of coaxing.

One of the wires on the power cable connects directly to the power switch.  The other wire is connected to a wire from the razor via a crimp connector.  The first step was to de-solder the wire from the power switch.  I could not find any de-soldering wick so I just applied some heat and forced the wire off.

Rather than cut the wires going into the connector and shortening the one from the razor, I used a vise to expand the connector and remove the wires.  That was surprisingly easy.

After disconnecting the power cable from the razor, I cut the wire just below where I thought the break in the cable was.  Next, I stripped about one inch off of the end of each cable.  The existing cable was tied in a knot that looked like a pretzel.  I tied the end of the remaining cable into a similar knot.

The final steps were to reconnect the individual wires to the switch and the razor.  I soldered one wire to the switch.  The other wire was connected to the wire from the razor.  I was able to use the original connector and re-crimp it.

I tested the razor and it appears to work!  Looks like I saved $30 by fixing it myself at the Makerspace.

Recent Updates to HESA

I've been spending time in small bursts recently working on the code for the Home Environmental Sensor Array.

Status Page Updated with Graphs
First of all, I updated the HESA status web page to display a graph of the current day's settings.  I found some php code called PHPGraphLib that makes it easy to create graphs with PHP.  In order to use PHPGraphLib, I made a new PHP page that reads today's readings from the database and puts them in an array variable.  Then, the data in the array is added to the class for the graph.  Finally, PHPGraphLib dynamically creates the graph as an image file on the server.  The main HESA status page calls the php page with the graphing code.  The PHPGraphLib page has some good documentation and was fairly easy to get going.

I also changed the HESA status web page to have a simple table with the high, low, average, and current readings for each sensor.  There are links to bring up the last 48 readings for each sensor.  In the future, I would like to make graphs for monthly and yearly data.

The final change I made to the Hesa status web page is to show at a glance if the HESA is working or not.  It checks the last time something was written to the database.  If the last update time is over an hour old, the title of the page changes.  Also, the status shows up at the top of the page.  Now, I can tell if the HESA is transmitting or not just by looking at the title of the web page.

Basic Design Failed.  Design Changed.  Backup Pump Added.  
Recently, I was replacing the sump pump in my basement.  While the pump was out, the water softener turned on and started dumping water into the crock.  When the crock filled up, the HESA detected the water and shut off power to the water softener -- exactly as designed.  What I found out, is that the water softener continues dumping water into the sink without electricity.  In other words, shutting off power to the water softener does nothing.  Yar!

In order to fix this design problem, I did a couple of things.  First, I bought a submersible pump and battery powered sump pump but I would prefer to have a battery backup solution for the whole system.

added it to the crock.  The submersible pump will move water from the crock for the basement sink to the crock for the drain tiles.  The sump pump in the second crock will then move the water outside.  This will help when the first sump pump fails for some reason.  I still have a problem when the power in the basement fails.  Yes, I could have a

Finally, I changed the programming on the HESA so the Power Switch Tail is normally off.  When the HESA detects water, it sends a signal to the PST to turn it on and provide power to the submersible pump.  This is the opposite of the way the HESA provided power to the PST originally but it fixes the design flaw.

Send All Clear Message
One small improvement I made is to send an "all clear" message to the email address if the water goes away.  Now, when I am doing some testing, people will get a follow-up email when all is well.

HESA Not Transmitting
I have been having problems with the HESA not transmitting.

First, There were some bugs in the code that would stop the program if it could not reach the internet.  I fixed those.

Next, the GFCI outlet that my network hub was plugged in to would trip on occasion.  The HESA would stay running but it could not send any data to the internet.  I had to fix this because the sump pump was also plugged into the same power outlet.

That GFCI outlet has a freezer plugged in to it, plus the sump pump, and a power strip with my network hub and a small clock.  For some reason, the outlet would trip when the sump pump tried to run sometimes.  Perhaps it was when the freezer motor was also kicking on.  I solved this problem by adding a bigger outlet and a second GFCI outlet.  Now, the freezer has its own 20 amp GFCI outlet.  The sump pump and power strip share the other 20 amp GFCI outlet.  I have not had any more problems with the GFCI outlets tripping since I made this change.

Even after these changes, once or twice a week, the HESA still stops transmitting.  When I check the processes that are running, there is no HESA program.  It appears that some kind of run-time bug causes the program to stop.  I need to start recording everything that happens in a log file so I can see where it stops.  Then, I can fix the code to handle the errors.

Until then, I made a change the /etc/rc.local file to hopefully restart the program if it fails.  Here is the code.

until sudo python /home/pi/python/hesa.py; do                
    echo "HESA crashed with exit code $?.  Respawning.." >&2 
    sleep 1                                                  
done                                                         

The HESA rebooted and started just fine.  We'll see if this change to the rc.local file fixes the HESA from stopping or not.

Power Connector for Chromebook Fixed

After about nine months of use, the power supply for our HP Chromebook stopped charging.  It looked like some wiring broke close to the end of the connector.  Too much flexing where the cable plugs in to the computer finally caused the wire to break.  What to do?

Best Buy sells a universal charger for $55.  That's bit steep.

Fortunately, I am a member at the Milwaukee Makerspace.  A few Fridays ago, I took the broken PSU to the 'space in hopes of saving myself $55.

My first idea was to find a power supply with a similar end.  I looked through the power supplies on the hack rack at the Makerspace.  There were plenty of old PSUs on the rack but none were an exact match.

Option two was to fix the connector on the current PSU.

To start, I cut away the plastic covering on the connector to reveal the wires.  Curiously, there are three conductors in the cable -- one white, one black, and one blue.  The white wire is hot.  The black wire is the return.  No idea what the blue wire is for.  I probably would need to break open the power supply brick to see what the blue wire is connected to.

The white and black wires were a bit frayed.  This was the problem.  I cut through the wires to separate the connector from the PSU.  Next, I used a Dremel tool to grind away the hard plastic that covered the connections on the connector.

Finally, I soldered the wires to the connect.  Heat shrink tubing was used to cover the wires.  The hole thing was also wrapped with electrical tape.

A quick test showed that the repair was good.  It has been charging the Chromebook for the last few weeks.

It felt good to fix the PSU.  Plus, saving $55 pays for one month at the Makerspace.  Bonus!

phpMyAdmin Works on HESA

I spent Labor Day weekend working on the Home Environmental Sensor Array on my Raspberry Pi.  I want to start reading and writing data on MySQL tables on the Raspberry Pi.  In order to make this easier, I need to use phpMyAdmin on my laptop to manage the MySQL databases on the Raspberry Pi.  There were several things I had to do to get this working.

First, phpMyAdmin tries to only connect to the MySQL server on the localhost.  I found a web page that explained how to get phpMyAdmin to connect to MySQL on another device.  Basically, I had to edit the config.inc.php file in the /etc/phpmyadmin folder.  The lines below were added after the section like it that setup the localhost connection.

$cfg['Servers'][$i]['verbose']         = 'HESA';$cfg['Servers'][$i]['host']            = 'hesa.local';$cfg['Servers'][$i]['port']            = '3306';$cfg['Servers'][$i]['connect_type']    = 'tcp';$cfg['Servers'][$i]['extension']       = 'mysqli';$cfg['Servers'][$i]['compress']        = FALSE;$cfg['Servers'][$i]['auth_type']       = 'cookie';$i++;

One thing to note is that these lines can be added to this file for every server that you want to control with this copy of phpMyAdmin.

Next, I had to go to the Raspberry Pi and tell MySQL to allow connections on the public internet connection and port 3306.  This is done by editing the /etc/mysql/my.cnf file and changing the bind-address variable in the [mysql] section to the local IP.  In my case, it looked like this:

bind-address = 192.168.0.58

Finally, I had to setup security for the users in MySQL.  I started up the mysql command line tool and executed a command like this:

GRANT ALL PRIVILEGES ON *.* TO 'USERNAME'@'%' IDENTIFIED BY 'PASSWORD' WITH GRANT OPTION;

Now that I am documenting all of this, it seems pretty simple. Its hard to believe that I spent so much time trying to get this to work.  Here is the end result.  Now, there is a Server Choice dropdown that shows all the servers, I can connect to from my laptop.

After getting this working, I created tables for the data that I store on the rynok.org website.  I also mostly copied data from the production site to the database on the Raspberry Pi.  The RJ comments table did not fully copy.  There is probably something wrong with the variable size for the id column.  I'll deal with that later.

Tried Soldering the USB Connector to the PCDuino

I did not post this right away but about two weeks ago, I attempted to re-attach the USB port to the pcDuino that I am working on.  The USB port got disconnected soon after I started working with the pcDuino.  The design of the board is such that a USB cable does not fit correctly when an HDMI cable is plugged in.  The first picture below shows the USB port separated from the board.

The picture below is me trying to solder the USB port back onto the board.  I used a microscope at the Milwaukee Makerspace to see the work since the connections were so small.  I tried to take my time to do it right.  The USB port was solidly connected to the board when I was done and it looked like a decent job but the board still does not power up when I plug a USB cable into it.

Motorshield Assembled for pcDuino v2

Today, I continued working on the Wifi Enabled, Remote Controlled, pcDuino Powered, Video Surveillance Robot.  I bought a MotorShield v2.3 from Adafruit.  It came mostly assembled for some reason.  I simply had to solder on the connector pins.  That was pretty easy.  (See the pictures below.)

The next step is to test an Arduino script to run a motor.  The problem is that I need to run a GUI interface on the pcDuino.  This means that I need to have both a keyboard and mouse plugged in to the one USB port on the pcDuino at the same time.  I do not have a USB hub and I could not find one at the Makerspace.  I thought about making one but it looks like I would have to make my own PCB.  Probably not worth it.

So, I will have to put off testing the motor shield until I get a USB hub.  In the meantime, I downloaded the Arduino script files for the board from Adafruit.  The files were in a zip format, that I downloaded to my laptop.

In order to get the zip file to the pcDuino, I installed FTP server on the pcDuino by executing sudo apt-get install vsftpd.  Then, I used FileZilla to move the zip file to the pcDuino.

Whenever I get a USB hub, I will be ready to test the motor.

Unassembled motor shield.

Bottom view of shield with pins soldered on.

Top view of shield with pins soldered on.

The shield attached to the pcDuinoV2.

HESA Now Recording Temperature and Humidity

After getting the HESA to write data to a SQL database, I feel like I need to measure more things.  This week, my new DHT 22 temperature and humidity sensor arrived from Adafruit.  I spent a few hours Home Environmental Sensor Array.
this morning hooking it in to the

Adafruit makes it super-easy to use the DHT22.  They have their own code library for Python.  There are a few steps to get the code installed.  Full instructions are here.

The first step is to download the code from github to the modules folder on the pi.

git clone https://github.com/adafruit/Adafruit_Python_DHT.git

The next step is to update the python development library.  Mine was up-to-date so I did not need this.

The final step is to install the DHT code library into python so it can be loaded as an include.  The Adafruit code from github comes with a program that does this automatically.  All I needed to do was cd into the correct folder and type

sudo python setup.py install

Next, I wired the DHT 22 into my Raspberry Pi.  It has four pins but only uses three.  Pin one goes to power.  Pin two connects to a GPIO pin to read the settings.  I used GPIO 7 or physical pin 4 on the Pi.  Pin two also connects to power through a resistor.  Pin four connects to ground.

The code to read the temperature and humidity is simple:

humidity, tempC = Adafruit_DHT.read_retry(sensor, dhtPin)

 The sensor variable tells the function what model sensor we are using.  In this case, sensor = 22.  The dhtPin variable tells the function which physical pin on the Pi pin 2 on the DHT is connected to.

The function sends back the humidity and temperature.  The temperature is in Celsius.  I convert it to Fahrenheit with this formula:

if tempC is not None : tempF = '{0:0.1f}'.format(1.8 * tempC + 32)

This formula also formats the temperature to have only one decimal point.

The code for the HESA now sends temperature and humidity readings to my SQL server database once an hour.  I also changed the code so it updates my local web page once every ten minutes and updates the database once every sixty minutes.  Before this, it was simply counting cycles and estimating the times for updating.

The link to view the data on the webpage is here.

Setting up the pcDuinoV2 -- Wireless and xWindows

I spent some more time working on the basic setup of the pcDuinoV2 that Pete from the Milwaukee Makerspace asked me to play with.

First of all, the board was booting up into xWindows on startup.  I thought I disabled that feature using the configuration program that is in the OS but apparantly not.  I managed to get xWindows to stop loading by creating a file named lightdm.override in the /etc/init folder.  The only line it had was one word: 'manual'.  

Now, the device boots to a text-based screen but the resolution looks like it is 1024x768.  In order to fix that, I had to run the configuration program from the command line by typing 

sudo board-config.sh

 and then setting the screen resolution back to 1152x864-75.  Rebooted.   The screen still came up in the lower resolution.  Maybe there is a permanent fix for this but I don't have time to research it.  It is pretty easy to set the screen resolution after bootup.

Next, I worked on the wireless network card.  There are some pretty good instructions about enabling a wireless NIC in Ubuntu at this website: http://www.linux.com/learn/tutorials/374514-control-wireless-on-the-linux-desktop-with-these-tools

First, I created a file named wpa_supplicant.conf in the /etc folder.  It had these lines in it:

network={    ssid="MilwaukeeMaker"    psk="secretPassword"}

Next, I put these commands in /etc/network/interfaces

auto wlan3iface wlan3 inet dhcp    pre-up wpa_supplicant -B -Dwext -i wlan3 -c /etc/wpa_supplicant.conf    post-down killall -q wpa_supplicant

That's it.  The initial setup of the pcDuino is done.  

• it boots to the command line
• can connect to it at pcDuinoV2.local on any network because of Avahi
• all upgrades are done (updates still don't seem to work)
• wireless networking works

The next phase in this project is to build the robot base and control it with the

pcDuino.  In order to keep things moving, I ordered a Motor/Stepper/Servo Shield for Arduino v2 Kit from Adafruit.  

Since the pcDuino has Arduino compatible pins on it, shields made for the Arduino will work with the pcDuino.  I can use the motor shield to learn how to control motors with the pcDuino.  That should take a few weeks.  In the meantime, I will try to find parts for the base.  I'd like to find or make as many parts as possible at the Makerspace.  

Finally, I think I would like to make a robot that looks like Wall-E.  This means, I will need treads instead of wheels.  I did a bit of research into treads and they are not cheap.  Maybe I can 3D print something. 

Fun With The pcDuino V2 -- First Looks

Pete from the Milwaukee Makerspace asked me to play around with a pcDuinoV2 that the 'space had sitting around.  I am tasked with making something awesome with it.  One idea I had was to make a  wifi enabled, remote controlled video surveillance robot.

At first, I was thinking that the robot could roam around the Makerspace, controlled by curious people on the internet.  On second thought, that would be a bit creepy.  Plus, the robot would get under people's feet or stuck on stuff.  Maybe the robot would be more accepted by the Makerspace members if it looked like a Dalek.  Think about it.  A five foot high Dalek driving around the Makerspace, controlled by someone on the internet.  That is not at all creepy.  Also, it would probably be pretty easy to add a speech synthesizer to the robot.  The person on the internet could type in some text and the synthesizer would speak it -- in a Dalek voice.  "Exterminate!  Exterminate!"  Awesome!

Another idea would be to combine the robot with the elevated train project that was discussed on the Makerspace's Google Group a year or so ago.  The original idea was to have an elevated train track that ran near the ceiling in every room of the Makerspace.  The track would be a big loop around the 'space.  In this case, instead of a train, the remote controlled robot would be on the track.  People could make it move around and point the camera at interesting things.  The robot would not get in anyone's way and possibly be less creepy.

Okay.  Enough daydreaming.  First things first: I need to make sure that the pcDuino works and get familiar with it.

The pcDuino has a USB port as a power input. That port is on the bottom of the board right next to the DVI port. I don't have a monitor with a DVI input. I have a DVI to HDMI converter that I can plug an HDMI cable in to.  The problem is that both a USB cable and the converter can not be plugged in at the same time. I was hoping that I could get both things plugged in at the same time if I applied a little pressure. Unfortunately, the extra force caused the USB port to separate from the board, i.e., I broke it off.  See the picture to the right. (Note to self: stupid decisions are made when tired.) 

The components on the pcDuino are surface mounted. I suppose it is possible to reattach the USB connector to the board but someone with better soldering skills than I would have to do it. 

Thankfully, the pcDuino has another USB port (labeled USB OTG) on the other end of the board.  It will also act as a power input port.  I used an external power supply that puts out 4.5V and 0.5A.  That is not enough to power the pcDuino when it runs xWindows.  Every time it started running xWindows, the screen would shutoff and I could not do anything.  I put the device away for a day or so.

Yesternight, I worked on the pcDuino some more at the Milwaukee Makerspace.  Again, I started out by using an external power supply for power through the USB OTG port.  The device would power up and start booting.  As soon as it started xwindows, the monitor shut off.  The power light was on and both RX and TX lights were on steady.

Next, I plugged the USB cable that supplied power into my PC's USB port and rebooted the device.  This time the screen stayed on in xwindows.  I guess my PC provides more Amps than the external power supplies I was using.  One problem solved.

Next, I plugged a USB keyboard into the USB A port and rebooted the device.  Pressing F8 during POST got me into the configuration menu.  Using the configuration menu, I changed the screen resolution to 1152x864-75.  Note: the default user is ubuntu with a password of ubuntu.

I tried running apt-get update to update the Linux operating system.  It ran for a few minutes then gave an error saying, "W: Conflicting distribution: http://www.wiimu.com pcduino Release (expected pcduino but got  )".  Not sure what is wrong.

Next, I ran apt-get upgrade.  It ran for about an hour and installed a bunch of upgrades.  Re-trying apt-get update yielded the same results as before.

I wanted an easier-to-use text editor, so I installed nano.

Also, I installed avahi.  (Full instructions are here.)  Then, I changed the host name to pcDuinoV2 in /etc/hosts and /etc/hostname.  Now, it is possible to use ssh to connect to the device at pcDuinoV2.local on any network.  There is not need to determine the IP address assigned to the device.

Finally, I tried to get the wireless network card working but I could not figure it out.  There is a website that has some information about this: http://www.linux.com/learn/tutorials/374514-control-wireless-on-the-linux-desktop-with-these-tools.  Obviously, there has to be a better way.

One last thing, the device still boots into xwindows.  I need to figure out how to turn that off.

Well, that was enough work for one night.  Next time, I'll get the wireless network card working.  I also need to find a powered USB hub so I can use a keyboard and mouse at the same time, if needed.