----- As a long time fan and user of IFTTT.com we would see the Numerous Channel from time to time and wonder what it did, how it could be used, etc. The Numerous tagline is "Numerous follows the most important numbers in your life and keeps them all up to date, all in one place" and that certainly got our attention. ----- Numerous runs on the iPhone and the app has a fantastic UI. The developer must be some rare artist/SWE hybrid type or something. The app flows well, takes advantage of new iOS features (TouchID, Apple Watch, etc.) and is easy to personalize. The graphs are clear and it even lets you customize when you get notifications (value to big/small, value change, change percentage exceeded, comments updated) and more. It short; it is a joy to use. Also, there are dozens of pre-programmed "metrics" that you can follow. Check them out. They are interesting and useful, but could get boring and after a while you will want to roll your own metrics to track more personal data useful for your applications. ----- That's where this blog post steps in. Numerous is really easy to get your personal data into it. After only a short time we had created "numerous" Numerous App metrics to: - track temperature/humidity sensors scattered around the house - track Internet UP/DOWN status - track security system triggers - track UP/DOWN status of LAN devices (security cams, Raspbery PIs, Imps, etc.) - several other miscellaneous things.... ------ How to get data into Numerous? One way is to use the Maker Channel on IFTTT.com as a trigger to the Numerous Channel on IFTTT.com. This requires no coding and is an easy way to pass three variables in one Maker Channel event trigger. If you want to include the Maker Channel trigger URL into a Python or PHP script the applications are endless. If you don't mind a little extra Python code, the task is almost as easy and offers more power and flexibility. To give credit where credit is due, it is made simple with the Python API App by outofmbufs. Here's my simple example using Python and a Raspberry PI to get data to the iPhone. The example shows how to create a Numerous metric, write data and comments to it, and view a graph of the data. ----- Run the Numerous app on the iPhone and create a new 'metric'. See the "+" sign in the upper right. Click that.
----- Give your metric a name. Don't worry about what you call it, you can change it later. Remember, I told you the app was flexible....
----- After you create the metric you can customize the way it looks. Change the title and description to suit your needs, add a meaningful background image, input data manually, set privacy and notification setting, etc. There is even a way to set the units. I put the units as "megaFonzies" in the example to denote how cool the Numerous App is.
----- Making the appearance pretty is fine, but what we want is to feed the metric data from the Raspberry PI via a Python script. For that you need two numbers: - your personal and secret API key: Get this by selecting "Settings/Developer Info" from the main screen of the Numerous app. Don't share this API key. It will start with "nmrs_" and is shown as "nmrs_xxxxxxxxxxx" in the source code example below. - the METRIC ID that you are writing to: In the Numerous app click on the tile for the metric you just created and customized. In the upper right you will see the classic "menu bar" icon. Click that then "Developer Info" to find your METRIC ID.
-----
Modify the Python script below with your API Key and METRIC ID values and run it. Your metric will start recording the values that you feed it:
----- Want a graph of the data? Turn the iPhone to landscape mode. You can pinch to zoom in and out for both the X and Y axis! How cool is that? At least 52 megaFonzies!
----- That's pretty much it. The Python script example below will introduce you to all the basics. It writes the system clock seconds value to the metric, but that could be any value your RasPI can produce or scrape from the web. The Numerous metric in the example is 'Public' that anyone can view, update, and comment on. Feel free to use it for testing. Good luck! ----- # WhiskeyTangoHotel.com [OCT2015]
# Super easy way to track/graph RasPI data to your mobile device using NumerousApp. # This simple prog logs the "seconds" value of the localtime value to a Numerous metric. # The Numerpus mobile app will log, track, and graph the data for you. # Of course, this value could be a sensor reading, CPU usage, Core Temp, or any other numerical value.
# D/L the NumerousApp and install it on your mobile device. # iPhone: https://itunes.apple.com/us/app/numerous-lifes-most-important/id797642904?mt=8 # Google Play: https://play.google.com/store/apps/details?id=com.numerousapp # # See http://numerousapp.com/ for full APIs and other really cool applications.
# Also check out the Numerous integration to IFTTT.com for more awesomeness. # Numerous can act as a trigger and receive triggers from most IFTTT.com channels # Teaming the Maker channel on IFTTT.com with Numerous is VERY powerful!
# 1st, do a one time install from the terminal using "sudo pip install numerous" # Must have pip installed to do this: "sudo apt-get install python-pip" # Needed for the following import line. from numerous import Numerous
import time # Needed to get the system clock settings
MyKey = "nmrs_xxxxxxxxxxx" # Your personal Numerous App API secret key. MyMetric = "2884060434653363716" # Get this by clicking "Developer Info" from the numerous app # "2884060434653363716" is set as an open/public metric # Anyone can write to, so you just enter your personal API key to test. # Link to load the metric to the app: https://nmrs.co/m/lwtm3kymv2tg # Set up for calls nr = Numerous(apiKey=MyKey) metric = nr.metric(MyMetric)
# This will return the Numerous App Label string. label = metric['label']
# This will return the current value of the metric Current_value = str((metric.read()))
# Let's get the current seconds value of the system clock, convert that # to a number, and write that seconds value to the Numerous metric Timestamp_seconds = int(time.strftime("%S", time.localtime())) metric.write(Timestamp_seconds)
# Uncomment the next line to add a like (a thumbs up) to the Numerous metric #metric.like()
# This will add a comment to the Numerous metric Comment_update = "System timestamp is: " + time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime()) metric.comment(Comment_update)
#Print info to the screen print " " print time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime()) print "Metric Name: " + label print "----------------------" print "Current value:" + Current_value # returns last current value of the Numerous metric print "New value: " + str(Timestamp_seconds) # the value written to NumerousApp -----
It is a pretty commonly uttered question (sometimes loudly) around the home or office; "Is the internet up?" As the goto IT Support Manager around the house this can get a little tiresome. Most of the time the internet is up and it's a user or personal device problem that can be solved with a re-boot, re-load, re-etc. Sometimes the internet is really down requiring a router and cable modem reboot or a call to the ISP. Wouldn't a simple visual check that anyone could quickly understand be helpful? Plus, as a bonus, provide some general network health statistics with a screen print and an hourly update to a Google Drive spreadsheet.
This project is amazingly useful and incredibly simple to duplicate. If you already have a Raspberry PI it is very cheap to implement.
----- What it does and how it works:
The Raspberry PI runs a Python program that test pings 10 internet sites that you to determine to provide the status of your internet connection.
GREEN: 7 or more sites return a successful ping.
Green LED on. Updates the stats. YELLOW: 6 to 4 sites return a successful ping.
Yellow LED on. Updates the stats. RED: 3 or fewer sites return a successful ping.
Red LED on. Updates the stats.
To make the program run faster and not burden the network with outgoing pings, all 10 sites are not pinged on each run. The ping test rotates through the 10 sites. If the selected site does fail the ping test, the program goes into "Deep Probe" and checks all 10 sites to determine the connection status. "Deep Probe" runs are tracked for the status report that prints to the screen.
Each hour a status report is appended to a Google Drive spreadsheet via the Maker channel at IFTTT.Com.
-----
For a visual output we went with a device that anyone can identify with, a simple $8 toy traffic light from Amazon. For $8 you get a lot. The light is well build, looks great, and is a full 7" tall with three LEDs already installed. It also comes with 12 little toy cars that you can give away; you don't need those. Next remove the four screws at the bottom of the base. You are going to see four wires that lead up to the three LEDs in the traffic light. Cut those wires and free them from the little ON/OFF switch and microcontroller that was meant to control the blink patterns for the non-hacker. Now you should only be left with four wires. The LEDs are wired common athode (+). The simple schematic below shows the hookup for each LED and their connection to the Raspberry PI. Double check the wiring for your traffic light with a button cell battery to see what wire lights each LED.
-----
You don't need to open the back, but if you did it would look like this:
-----
After you wire in the toy traffic light it will look something like this:
-----
Now you will need to load the Python source code provided below, but before you do, a few simple edits are required:
- Find in the code where it says "# Identify ten PING 'friendly' sites". In that section put in ten IP addresses or DNS names that are "ping friendly". Not all sites allow you to ping them, so test ping them manually first from a command line.
- Find the variable named "Delay_between_tests". In the program it is set to 15 (for 15 seconds). Adjust this if you want to test more or less frequently.
-----
That's about it, now run the program. The RasPI will take the traffic light through an LED self test. Then it will do an initial first run deep probe ping test on all ten of the test sites; the LEDs will self test during this as well.
-----
From then on the little toy traffic light will answer that all too common "Is the internet up?" question. In addition, as the local IT Support Manager, you will have access to a running history in a Google Drive spreadsheet and the status output table below to impress your friends:
-----
Here is the Python code that makes it all work. Of course, as mentioned above, you will need to supply your own list of ten ping friendly internet sites instead of "yourtestsite-1.com", etc.
# Is the Internet UP? / August 2015
#
# Project details at:
# http://whiskeytangohotel.com/internetup
#
# Using a Raspberry PI we ping a 10 IP addresses and light up a Red, Yellow, or Green LED
# to display the 'health' of our internet connection.
#
# SEPT 3, 2015: Adding IFTTT.com Maker channel to log status to Google Drive each hour.
#
# At least 7 of 10 successful pings to light the Green LED
# 3 or fewer of 10 successful pings for Red LED
# Anything in between and light the Yellow LED
#
# Program does not ping all 10 sites each time. For speed, etc. one of the sites
# is tested at each run. If that ping fails, 'deep probe' mode involkes and all sites are tested
# to determine latest Red/Yellow/Green status.
#
# As an output device we used a $7 toy stoplight from Amazon.com. Search:
# "Dazzling Toys Racer Cars and Traffic Set - 7" Traffic Light with 12 Pull Back 2" Racer Cars"
#
# In addition to the LED stop light status. The details below are screen printed on each run.
#
# Tue, 01 Sep 2015 05:03:32. Update interval: 15 seconds.
# Status report: GREEN. Runs: 1812. DeepProbes: 6. Runtime: 8:42:44.448047
# -----------------------------------------------------------------------------------
# Last check: UP pingfriendlysite-1.com was UP 188 of 189 pings. 99% uptime.
# >>>Last check: UP pingfriendlysite-2.com was UP 189 of 189 pings. 100% uptime.
# Last check: UP pingfriendlysite-3.com was UP 187 of 188 pings. 99% uptime.
# Last check: UP pingfriendlysite-4.com was UP 187 of 188 pings. 99% uptime.
# Last check: UP pingfriendlysite-5.com was UP 188 of 188 pings. 100% uptime.
# Last check: UP pingfriendlysite-6.com was UP 188 of 188 pings. 100% uptime.
# Last check: UP pingfriendlysite-7.com was UP 188 of 188 pings. 100% uptime.
# Last check: UP pingfriendlysite-8.com was UP 188 of 188 pings. 100% uptime.
# Last check: UP pingfriendlysite-9.com was UP 188 of 188 pings. 100% uptime.
# Last check: UP pingfriendlysite-10.com was UP 185 of 188 pings. 98% uptime.
# ------------------------------------------------------------------------------------
#
# RED: 0 events. Last event: none detected
# YELLOW: 0 events. Last event: none detected
# GREEN: 1812 events. Last event: Tue, 01 Sep 2015 05:03:32
#
from __future__ import division # don't round interger division to 'zero'
import time
import datetime # used for timestamp math
t0 = datetime.datetime.now() # for timestamp math. t0 is the time the program run started
runtime = 0 # localtime minus t0 = total runtime of the program
# Set up for IFTTT triggering
import requests # needed to get https request to IFTTT web page
Current_hr = time.strftime("%H", time.localtime()) # use this var to update trigger IFTTT at each hour change
IFTTT_hr = "999" # we will only trigger IFTTT if this is diffent from Current_hr
MAKER_SECRET_KEY = "xxxx-my-maker-ifft-key-xxx" #this is my IFTTT Maker Channel secret key
Delay_between_tests = 15 #in seconds. Delay is in last line of code
Loop_count = 0 # track how many times the Red/Yellow/Green status was updated.
Deep_probe = 0 # how many times was a deep probe required; Single_test_site ping test failed
Single_test_site = 0 # used to select non deep probe ping test. Rotates thru the 10 IPs
Last_Red = "none detected" # timestamps for when condition happened for screen report
Red_Event_Counter = 0 #also count number of time condition occured
Last_Yellow = "none detected"
Yellow_Event_Counter = 0
Last_Green = "none detected"
Green_Event_Counter = 0
import os # allows for the ping calls
import RPi.GPIO as GPIO # We will be using the RasPI GPIO to control the three LEDss
GPIO.setwarnings(False) # suppress screen from showing GPIO errors
# to use Raspberry Pi board pin numbers
GPIO.setmode(GPIO.BOARD)
# set up GPIO output channel
# I/O 15 = RED
# I/O 18 = YELLOW
# I/O 22 = GREEN
# NOTE: LOGIC LOW TURNS ON THE LEDs (they are active LOW)
GPIO.setup(15, GPIO.OUT)
GPIO.setup(18, GPIO.OUT)
GPIO.setup(22, GPIO.OUT)
#Turn off all the LEDs
GPIO.output(15,GPIO.HIGH)
GPIO.output(18,GPIO.HIGH)
GPIO.output(22,GPIO.HIGH)
SiteStatus = [1,2,3,4,5,6,7,8,9,10,11] # Pass/Fail of the site ping
UpTally = [1,2,3,4,5,6,7,8,9,10,11] # count succesful pings for each site
PingCount = [1,2,3,4,5,6,7,8,9,10,11] # count how many times each site is pinged
PingSite = [1,2,3,4,5,6,7,8,9,10,11] # holds the IP or DNS name of the site being pinged
print " " # print startime, self test, etc...
print time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime())
print "-------------------------"
print "LED Self Test in process..."
print " "
print "Test Pings Sites are:"
print "-------------------------"
for checksite in range (1,11): #init some vars, display sites on screen during self test.
UpTally[checksite] = 0 # if site is UP when tested then incremented
PingCount[checksite] = 0 # if site is tested then increment
SiteStatus[checksite] = "---"
print checksite, PingSite[checksite]
# Self test the LEDs by blinking them. Remember; active LOW.
st_delay = 0.20
for st in range (0, 5):
GPIO.output(15,GPIO.LOW) # Red
time.sleep(st_delay)
GPIO.output(15,GPIO.HIGH)
print " "
print "Test pinging all sites for first run..."
print " "
# get a 1st run baseline so the status printout looks normal/clean
LED_status = 0 # LED_Status keeps score of the successful pings on the test sites
for checksite in range (1,11):
# All LEDs on during the 1st run pings; flash effect
print " "
print "All LEDs on..."
GPIO.output(15,GPIO.LOW)
GPIO.output(18,GPIO.LOW)
GPIO.output(22,GPIO.LOW)
# All LEDs off; flash effect
print " "
print "All LEDs off..."
GPIO.output(15,GPIO.HIGH)
GPIO.output(18,GPIO.HIGH)
GPIO.output(22,GPIO.HIGH)
time.sleep(.5) # little delay for the LED off
print " "
print "Self Test complete..."
print " "
while True: #Loop forever to check and display ping test status
Loop_count = Loop_count + 1
# Only test ping all sites if the one site tested sites fails the ping
# Here we test ping a single site. Next time we ping test the next site on our list of 10.
if Single_test_site < 10: # single test site selection
Single_test_site = Single_test_site + 1
else:
Single_test_site = 1
hostname = PingSite[Single_test_site] # OK, now the have selected one of our ping test sites
print "Ping site: " + hostname # so let's test ping it with os.system command
print " "
time.sleep(1.5)
PingCount[Single_test_site] = PingCount[Single_test_site] + 1
response = os.system("ping -c 1 " + hostname)
if response == 0:
# tested site is up. all is fine. don't deep probe, but update the tally stats
SiteStatus[Single_test_site] = "UP"
UpTally[Single_test_site] = UpTally[Single_test_site] + 1
Led_status = 10 # insure GREEN condition
else: # If selected site is down, so now we call for a vote by testing all sites. Let's deep probe.
print " "
print "Selected site failed ping test. Intiating deep probe..."
print " "
Deep_probe = Deep_probe + 1
LED_status = 0
for checksite in range (1,11):
hostname = PingSite[checksite]
PingCount[checksite] = PingCount[checksite] + 1
response = os.system("ping -c 1 " + hostname)
if response == 0:
#hostname 'is up!'
SiteStatus[checksite] = "UP"
LED_status = LED_status + 1
UpTally[checksite] = UpTally[checksite] + 1
else:
#hostname 'is down!'
SiteStatus[checksite] = "DOWN"
time.sleep(.1)
#Adjust the LED status light and screen print a report
if (LED_status >= 7): #Hurray, looking good. Turn on Green LED. All others off
GPIO.output(15,GPIO.HIGH) #Red OFF
GPIO.output(18,GPIO.HIGH) #Yellow OFF
GPIO.output(22,GPIO.LOW) #Green ON
Status_Color = "GREEN"
Last_Green = time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime())
Green_Event_Counter = Green_Event_Counter + 1
if 3 < LED_status < 7: #Things are shakey. Yellow LED on. All others off
GPIO.output(15,GPIO.HIGH) #Red OFF
GPIO.output(18,GPIO.LOW) #Yellow ON
GPIO.output(22,GPIO.HIGH) #Green OFF
Status_Color = "YELLOW"
Last_Yellow = time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime())
Yellow_Event_Counter = Yellow_Event_Counter + 1
if (LED_status <= 3): #Oh no, looking bad. Turn on Red LED. All others off
GPIO.output(15,GPIO.LOW) #Red ON
GPIO.output(18,GPIO.HIGH) #Yellow OFF
GPIO.output(22,GPIO.HIGH) #Green OFF
Status_Color = "RED"
Last_Red = time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime())
Red_Event_Counter = Red_Event_Counter + 1
# At each hour trigger IFTTT and update Google Drive Spreadsheet. Will always trigger on 1st run
Current_hr = time.strftime("%H", time.localtime())
if (Current_hr != IFTTT_hr):
IFTTT_hr = Current_hr
url = url = "https://maker.ifttt.com/trigger/trigger_stat/with/key/" + MAKER_SECRET_KEY + "?value1=" + Red_print + "&value2=" + Yellow_print + "&value3=" + Green_print
res = requests.get(url)
#print str(res) + " is web request result for BT device: " #used only for debug
time.sleep(5)
time.sleep(Delay_between_tests) #wait some before next ping test
-----
If you're still with us, thanks and if you duplicate the build let us know!
The Charger Doctor is a sub $2 device that displays voltage and current levels while charging a USB device. There have been several teardown write ups on the Charger Doctor. It's useful, but does have some limitations. For example, it doesn't charge iOS devices and it seems to effect the reliability of the WiFi connection on our Raspberry PIs. This made us want to take a closer look at what the output was doing.
Here we use a Keithley DMM7510 to monitor the Charger Doctor output. The DMM7510 is a precision instrument with 7.5 digits of resolution and 14 PPM accuracy. It has a touch screen interface with graphical output, advanced triggering options, cursors, and a whole lot more. Plus, it is fast (very very fast); capable of sampling at 1M/s. To sum it up, it's pretty darn cool!
-----
In the video the DMM7510 shows a decrease in voltage when the Charger Doctor displays current. Also, some instability when displaying voltage. But remember, the Keithley DMM7510 is a very sensitive instrument. The change in voltage looks big on the screen, but it is really very small.
-----
The overall voltage swing is only 7.536mV or 0.00753 Volts. That's not a lot.
-----
And taking a closer look at that instability when the Charger Doctor displays voltage we see that it is only 1.256mv peak to peak; that's just 0.001256 Volts. Really, that seems exceptional for a sub $2USD device.
-----
There is a lot of discussion on the web as to why iOS devices don't charge via the Charger Doctor. With the stability shown, I'm not sure why the Charger Doctor effects the WiFi reliability of the Raspberry PI, but I can say it does. We set the Keithley DMM7510 to camp on the Charger Doctor output signal and trigger on a larger glitch or voltage spike to give us a clue. After about 15 minutes the Charger Doctor remained stable within the trigger limits and we moved on with our life. We do have to take into account that the Charger Doctor was effectively unloaded while making these measurements and that could make a big difference.
-----
Thanks for stopping by.
-----
What hobbyist doesn't want a CNC machine? But realistically, how many can really justify the need for one? Not me, but we did want to learn about CNC machines and experiment with GCODE. If you are wanting to do the same; keep reading...
We had an Arduino UNO sitting around doing nothing as well as some stepper motors we rescued out of an old laser jet printer. That's a good start for the project, but some hardware/software to drive and control those stepper motors was still needed. Oh, and some PVC pipe and connecting joints to construct a mill platform, don't forget that.
-----
After a bit of searching we decided to use the Protoneer CNC Shield for Arduino. You can get this shield for about $20US. It comes completely unassembled, but a soldering iron and an hour or so of time fixes that.
Before assembly it looks like a bag of parts. After assembly it looks like this:
-----
The Protoneer CNC Shield plugs right into the Arduino UNO just like any other shield. Of course, after you get it assembled you will want to test it. But wait, first you will need some software to communicate with the Arduino and drive the Protoneer CNC Shield.
The Protoneer CNC Shield is 100% GRBL compatible. This is great because it provides you with several software options for CNC control. I wanted something that was 1) free and 2) could be used with Windows or LINUX. I experimented with SketchUp, f-engrave, and GCODESENDER. In the end, I seemed to prefer GCODESENDER the best. YMMV.
-----
Here is my first test run controlling the X and Y axis steppers. Ahhhh, the sweet sound of progress:
Then added the Z axis:
-----
Before constructing the PVC "mill" I tested the rig on a Etch-a-Sketch. Seems to work well enough to continue.
-----
Next, thanks to Home Depot and their endless assortment of PVC accessories, the rig below was constructed. I did not use any PVC glue and the slide rails for the milling tray were held on with P-clamps and larger diameter PVC 'sleeves' for bushing/linear bearing.
-----
Here are a few first run tests of the rig in motion:
-----
Example of simple text:
-----
A bit more elaborate example:
-----
The rig works. Could you create an elaborate 3D design with it? Heck no, but that wasn't the point. It was; however, a great learning experience. With some effort, anyone could take this concept and improve it to something more useful if they desired. If you choose to take that path, drop us a line to let us know how it turned out. Thanks!
Nosey spouse? NSA tracking you? Just want to made sure you are not "available"?
If for some reason you want make certain your phone (or a visitors phone) is "blind" to location tracking, showing that iMessages are delivered, confirmation emails, GPS, etc. place the phone in a microwave oven.
Here we use a Tektronix RSA306 Real Time Spectrum Analyzer (which is located behind the PC screen) to demonstrate the effectiveness of a microwave oven as a RF screen room. Notice the RSA306 can "see" WIFI/Bluetooth signals when the door is open. When the door is closed anything inside the oven is "blinded" to all cell phone communications. All of them.
If you want to hide your phone (or hide someone else's) from all network communications, put it inside a microwave oven.
Oh, and don't turn on the microwave with your phone inside like this guy did!
-----
Braille is a Pebble smartwatch app that allows the vision impaired or anyone wanting to be discrete to check the time. If you are interested in installing this free app on your smartwatch just go to the Pebble App store and search for "Braille" or click on the image below.
Give us a "like" heart while you're there.
-----
If you haven't heard about the Pebble smartwatch you probably have been living under a rock (or a pebble). The Pebble has been one of the more successful KickStarter campaigns. We got ours a few months ago and immediately put it to use. Overall, the Pebble is a great value.
-----
One thing that is often handy is to be able to tell what time it is without looking at your watch. This can be useful in business meetings, on dates, or when it is dark like at a movie. Nothing says "I'd rather be doing something else" like checking the time. Also, this is an absolute requirement for the vision impaired.
Before getting the Pebble I solved this problem with the very innovative Bradley Timepiece; a watch specifically designed for the vision impaired. The challenge was to bring vision impaired features to the Pebble. Fortunately, Pebble has a nice cloud based SDK that allows a developer to upload custom apps to the watch and make them available to the public. With a bit of studying and some help from the Pebble Developer forums we were off and coding....
-----
How the "Braille" app works:
- Press UP button: Count one watch vibration for each hour.
- Press DOWN button: Count one watch vibration for every 10 minutes past the hour. An additional quick two vibrations is added if the time is closer to the next larger 10 minute interval. This gives a very quick resolution of <5 minutes (if you need to be more accurate, them it's time to look at your watch). For example: If it is 30-34 minutes past the hour the watch will give 3 long vibrations. For 35-39 minutes past the hour the watch will give 3 long vibrations plus two quick vibrations.
- Press SELECT button: Light the Pebble if the backlight is enabled.
- Bluetooth Alert: "Braille" also does a vibration alert for 5 seconds and inverts the screen if Bluetooth is disconnected. Handy for making sure you are not separated from your phone. Upon re-connection "Braille" will vibration alert again and turn the screen back to normal.
For the curious, the icon on the watchface is in the Braille pattern for the letter "B".
Thanks for checking us out. Enjoy the "Braille" app and let us know if you have any suggestions for improvement.
Almost all the aircraft flying overhead broadcast tracking information on 1.09GHz via ADS-B. ADS-B is an open protocol. So what? Well, it means you can decode it.
Once we learned about this our focus was set on building a rig to track overhead aircraft using the Raspberry PI. You can read all about the setup here.
----
The Software Defined Radio (SDR) we used comes with a small whip style antenna. Fine for testing purposes, but we wanted to extend our reception range.
The FlightAware forums turned us onto what looked like a simple low cost way to DIY a small quarter wave antenna that had proven results. The antenna design is by "atouk" and documented in a .PDF titled "My First ADS-B Antenna". The design is so straight forward you really only need to go off the dimensioned line drawing above, but the "My First ADS-B Antenna" document is worth the download.
----
It took about ten minutes to build the antenna. We went through a three step process to gauge it's effectiveness.
Step 1: Chart reception with the cheapie stock OEM whip antenna placed in a closet on the 2nd floor.
Step 2: Chart reception of the DIY quarter wave antenna placed in the exact same location as the OEM whip in Step 1.
Step 3: Chart reception of the DIY quarter wave antenna raised into the attic (actually only a few feet higher)
-----
Here are the Step 1 (OEM whip) results. Click on image to enlarge:
-----
Here are the Step 2 (DIY quarter wave, same position as QEM whip) results:
Okay, we show improvement! Notice the 'spider' chart outer rings are showing aircraft. Also, the sharp rise in plane count on December 14th.
-----
Here are the Step 3 (DIY quarter wave, moved to attic) results:
Moving to the attic yielded only a slightly higher plane count on the daily graph. But check out the the 'spider' chart; it does seem to indicate better coverage.
-----
The DIY quarter wave antenna is absolutely an improvement over the SDR OEM whip antenna and well worth the very small time and cost investment. Our roof decking has a 'shiny stuff' radiant barrier on it. The thought is the radiant barrier may be acting like a big metal blanket thrown over the antenna. If we moved the antenna outdoors there would certainly be more improvement. But for now our DIY quarter wave antenna will rest happily in the attic helping the Raspberry PI collect ADS-B data 24/7 and report it to FlightAware.
-----
Thanks for the visit and let us know how your rig improves!
-----
A friend of mine got a Pono music player this Christmas. The claimed advantage of the Pono player vs other music players is better sound fidelity.
So what does the Pono player do different? Normal CD music is sampled at 44,100 times per second (44.1Ks/S) and 16-bit resolution. The Pono is capable of playing music with an increased sample rate of 192,000 times a second (192Ks/S) and 24-bit resolution. A quick web search yields page after page of audiophiles debating these fidelity claims and we will leave that discussion to the experts.
------
Since Pono advocates see benefits in increasing sample rate from 44,100 times per second to 192,000 times a second, then just think about how awesome really turning up the sample rate would be!!! But how? Enter the Tektronix MDO3000 which can sample at an amazing 2,500,000,000 (2.5Gs/S) times per second and that's a lot!
-----
The Tektronix MDO3000 is a benchtop instrument that has some truly amazing capabilities that push it way beyond being just an oscilloscope. One of these features is the Arbitrary Function Generator (AFG) that can capture signals from any of the analog channels and play them back on command.
----
In the video below, we set the Tektronix MDO3000 to sample at a lazy 1,000,000 times per sec (1Ms/S). Then we use a PC to play a MP3 music file for capture into the instrument's waveform memory via analog channel 1.
-----
Next, with a few button clicks the music waveform we just captured is loaded into the instrument's AFG to make it ready for playback. Simple.
-----
The Tektronix MDO3000 AFG output is BNC connector on the back of the instrument. We connect to the AFG and plug into a speaker. The result: The most impractical (and expensive) MP3 player available, but with an impressive sample rate many, many times higher than the Pono player.
-----
This whole experiment means nothing, of course. We did it simply because "we could". If you do decide to go with a Pono (or a Tektronix MDO3000) as a music player remember that much of the sound quality is determined at the time of the original recording and not just at playback. Also your headphones, speakers, listening room, ears, etc...
-----
It takes some time for an electrical signal to travel down a wire or through a logic gate. Not much time, but some. It's called propagation delay (tpd) or "prop" delay. We had a 74HC04N on the breadboard from our recent Rasperry PI CPU Usage Tachometer project and decided (for reasons unknown) to measure the prop delay of this chip. The 74HC04N is a simple IC that turns a logic "0" into a "1" and turns "1" into a "0". It has "six" gates to "invert" digital signals; thus the name "hex inverter".
----
For our measurement setup we used the Tektronix MDO4104B-6 oscilloscope. It has plenty of what it takes to make this simple prop delay measurement and we had one handy. Since passing through one gate inverts a digital signal, passing the signal through two gates (or any even number of gates) will invert that signal back to it's original logic level.
Here is a 5VDC signal propagating though two gates. The yellow trace is the input and the blue trace is the output after passing through two gates. Using the scope cursors we measure the prop delay at 12nS (nS or nanosecond = 10EE-9 seconds). That's an average of 6ns per gate.
-----
Here is a 5VDC signal propagating though all six gates. Again, the yellow trace is the input. The blue trace is the output. The scope cursors measure the total prop delay at 33.2nS (as well as some signal degradation from loading) for an average of 5.53nS per gate.
-----
Is that prop delay good or bad? Well, we have to consult the device datasheet. For a 5VDC setup NXP specs their 74HC04N at 7ns per gate typical, so our chip is beating the spec! As far as it being good or bad depends on your application. For most low speed hobby projects prop delay isn't even a consideration. If you are designing high speed circuits then race conditions and prop delay specs become important to your design.
-----
UPDATE: Special thanks to all the .EDU sites for checking in!
We had an old car tachometer laying around the labs (beats me why...) that seemed perfect for some type of project. But what? Since it is pretty common to see a car looking tachometer as a CPU usage meter on the desktop of a PC we decided to create a hardware version of this for the Raspberry PI.
Basically what we are going to do is read the CPU usage on the Raspberry PI. Then convert that CPU usage value into a corresponding frequency. That frequency will be output via GPIO on the Raspberry PI pin 11 to drive the tachometer.
----
First step is to characterize the tachometer and find out what type of frequencies made the needle move. The Tekronix 3252C made easy work of that.
----
The spreadsheet below shows what frequencies move the tachometer needle to what position.
We also used this spreadsheet to calculate a multiplier to adjust the CPU usage reading on the RaspPI to a 0 RMP to 8000 RPM reading on the car tachometer. It's a pretty simple calculation and you can see how it is used in the Python source code below.
-----
The tachometer needs 12VDC to power it, but the input signal to move the tachometer needle needs to be 5VDC. A 7805 voltage regulator solves that problem. Also, to buffer the RasPI GPIO a 7404 was used to drive the RasPI signal into the tach. The connection looks like this:
----
Using some Python code the end result is this:
In the video you can see how moving the mouse around on the Raspberry PI increases the CPU usage making the tachometer reading increase. When the Chromium web browser is launched the CPU usage goes to 100% and the tachometer needle 'redlines'.
-----
The Python code is straightforward. Drop us a line if you decide to duplicate the build!
#
# Program makes a simple car tachometer read CPU usage percentage.
#
# WhiskeyTangoHotel.Com - December 2014
#
# To run this program you must first do a one time install
# of the following from the terminal commans line.
#
# sudo apt-get install python-pip python-dev
# sudo pip install psutil
# sudo apt-get install python-psutil
# see: http://sourceforge.net/p/raspberry-gpio-python/wiki/PWM/ for PWM info
import time
import psutil
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(11, GPIO.OUT)# Pin 11 drives the tachometer
#p = GPIO.PWM(channel, frequencyHz)
p = GPIO.PWM(11, 200) # move the tach needle to about 1/2 scale
#p.start(dc) # where dc is the duty cycle (0.0 <= dc <= 100.0)
p.start(50)
print ' '
print 'SELF TEST: Tach to about 1/2 scale for 5 seconds...'
time.sleep(5)
print ' '
i = 0# just a counter
adjust_cpu_to_hz = 3.8 # adjust_cpu_to_hz is calculated on the tach characterization spreadsheet.
# Tektronix 3252C was used to feed input into the tach to create the
# characterization spreadsheet. Discover how many Hz needed to move needle.
while(True): # loop forever
i = i + 1
# read the RasPI CPU Usage. Store the value in var cpu_usage.
cpu_usage = psutil.cpu_percent()
# use adjust_cpu_to_hz to scale the cpu_usage result to Hz within the tach's range
p = GPIO.PWM(11, cpu_usage * adjust_cpu_to_hz)
p.start(50)
print 'Run #:', i, ' ', cpu_usage,'%', ' ', cpu_usage * adjust_cpu_to_hz,'Hz out to tach'
time.sleep(3) # allow x secs to give the CPU a breather
