Tuesday, August 9, 2016

Tablet as GPS

I've been building up a stock 2008 Suzuki VStrom 650, into a more comfortable, better equipped adventure bike. One of the modifications I have made is to add the ability to use an old Nexus 7 wifi tablet as my GPS unit. I'm kind of a cheap guy, so as usual that means I've needed up spending more than necessary, in an effort to keep the investment cheap.

The first need was power. You can't take a multi-day ride with a tablet on maximum brightness and not have aux power. I purchased what looked like a rugged 12v USB socket from Amazon--unfortunately, it died before I could use it (no clue why--the wires show no sign of heat damage, the inline fuse is fine, and it has never been wet because I garage my bike at all times). At the time of this writing, I am back to the drawing board on this step.

The next challenge was the mount--how to secure a tablet to the bike. The tablet I have chosen, the Nexus 7 wifi, is really light. I purchased a rugged case for it, but even then it's well under a pound. My first effort was to try to hack a cup-holder phone cradle to work--I tore it apart till I just had the stem, but couldn't find a way to install it without 1) compromising safety and 2) damaging the very visible cockpit area. Finally, I bit the bullet and purchased a RAM Mount marine mount as well as and Adventure Tech GPS mount (http://www.adventuretech.biz/over-the-dash-gps-mounts.html) The mount install was painless and the RAM mount seems really secure. (NOTE: I had to push the photos quite a bit to get them lit up enough to see, so they're grainy):

  

The next challenge was mounting the tablet to the RAM Mount. The case I purchased has a rubber cover for the tablet, with a hard plastic back which separates from the rubber cover. I matched up the RAM mount mounting plate holes to the vertical and horizontal center of the rigid plastic back, drilled holes, and used some flathead automotive mounting posts to fix the plastic to the mounting plate.





Now I have a ruggedized tablet fastened to a RAM Mount, just above my instruments, which it is visible but not distracting. Using Bluetooth, I can connect my Sena headset to the tablet, where I receive turn-by-turn directions as well as music (the Sena can connect multiple devices, so I also have my phone connected, in order to take calls).

 

Why a tablet, instead of the Garmin GPS most riders carry? Price, convenience, and functionality.
  • The Garmin GPS is $500-$600 new. I already own the tablet.
  • The tablet has a camera which will take shots (still and video) right through the windscreen, so it's a great way to capture snippets from the road.
  • The tablet allows me several options in terms of GPS apps.
  • I can run Rever on my tablet, which is how I plan, track, and share rides with others.
  • The tablet also allows me to write and assemble blog entries.
  • With the tablet, I can connect to and pull content off my Nikon J5 as well as my GoPro, to enhance blog entries.
  • The tablet is lighter than a Garmin, but has a larger screen and much higher resolution.
  • With an Android device, I can keep in touch via social media whenever I stop. If I'm not somewhere where there is wifi, I can use my phone as a hotspot.
I proved this out on the road recently, riding from Salt Lake City to Ely, NV to Wendover and back to Salt Lake City. The tablet is a bit heavy - the VStrom fairing moves quite a bit already, but it's obvious there's additional weight on it. Nonetheless, the system worked quite well. Once I get the power issue resolve, this will be a great solution.

Friday, April 1, 2016

IoT Excitement - NodeMCU Pushes the Weather

If you read my previous post, you know I've been messing around trying to decide what IoT stack to use as I build out a variety of projects. I've  been messing with NodeMCU a lot lately, in fact I've been able to connect it to a BMP085 sensor and publish intranet web pages with temperature and barometric pressure.  In the process, I've learned a few things about NodeMCU (a few additional things).

Basically, I find NodeMCU to be great at doing very little. No, I mean that literally - if there's something IoT really small you need to do, NodeMCU might be the right device. Might...

  • Ironically, in my previous post I discussed how NodeMCU could be programmed via Arduino. I was worried it might take up more memory, though, than programming in Lua. According to this blog, however, the opposite is true. Lua, being an interpreted language, sucks up tons of memory. I found that to be true - my original code attempted to open two connections in the same function. It couldn't run due to memory errors. 
  • I've mentioned before, but using NodeMCU is a kludgey experience. The device is awesome in principle, and it's only in its infancy, but connecting and disconnecting the USB cable to reset the device time after time... It gets old after a while. 
  • Lua is a relatively straightforward language, but it has its drawbacks (including taken up memory for comments).It took me two separate evenings to figure out how to successfully make an http connection. 
Regardless, let's jump in... The mission was to connect my IoT device to the cloud. The goal was to publish data to Weather Undeground - goal achieved: https://www.wunderground.com/personal-weather-station/dashboard?ID=KUTWESTJ26

I decided to connect to Adafruits IOT site, as well, just to make a little spiffy control out of it: https://io.adafruit.com/johnover/weather

To upload data, I'm using a simple init.lua script, then the bmp180.lua script (standard), then the wu_lite.lua script I wrote:


-- BMP085 and NodeMCU Weather Underground
-- Submits temp and pressure to WUnderground

--**************************************************************
   alti=1509 -- set correction for your altitude location in meters
--**************************************************************
   wifi.setmode(wifi.STATION)
   wifi.sta.connect()
   sda=4   -- GPIO2 connect to SDA BMP180
   scl=3   -- GPIO0 connect to SCL BMP180
   pres=0    -- pressure
   temp=0    -- temperature
   oss=0   -- over sampling setting

--load BMP module and read sensors
function ReadBMP()
   bmp180 = require("bmp180")
   bmp180.init(sda, scl)
   bmp180.read(oss)
   pres = (bmp180.getPressure()/100+alti/8.43)/33.86388667
   temp = ((bmp180.getTemperature()/10)*9/5+32)
   --fare = (temp*9/5+32)
   --print("Pressure:    "..string.format("%.1f",pres).." inches")
   --print("Temperature: "..string.format("%.1f",temp).." deg C")
   --print("Temperature: "..string.format("%.1f",fare).." deg F")
   --print(" ")

   -- push to WUnderground
   host = "rtupdate.wunderground.com"
   param = "/weatherstation/updateweatherstation.php?ID=<WU_ID>&PASSWORD=<wu_password&" ..
 "dateutc=now&tempf="..string.format("%.1f",temp).."&baromin="..string.format("%.1f",pres) ..
      "&softwaretype=NodeMCU%20version%20.01&action=updateraw&realtime=1&rtfreq=2.5"

   print(host .. param)
   sendRequest(host, param)
   
   -- host = nil
   -- param = nil
   
   
   -- ******************************************************************
   -- adafruit io
   -- create http client http://benlo.com/esp8266/esp8266QuickStart.html
   -- ******************************************************************
   host = "io.adafruit.com"
   param = "/api/groups/weather/send.json?x-aio-key=<Adafruit_IO_key&temperature="
           ..string.format("%.1f",temp).."&pressure="..string.format("%.1f",pres)
   
   sendRequest(host, param)
  
   -- release module
   bmp180 = nil
   package.loaded["bmp180"]=nil
end



function sendRequest(host, param)
   conn = nil
   conn = net.createConnection(net.TCP, 0)
   conn:on("receive", function (conn, payload)
               success = true
      print(payload)
   end)
   
   -- once connected, request page
   conn:on ("connection", function(conn, payload)
print('\nConnected')
   conn:send("GET " .. param.. " HTTP/1.1\r\nHost: " ..host.. " Connection: close\r\nAccept: */*\r\nUser-Agent: Mozilla/5.1 (compatible; esp8266 Lua; Windows NT 5.1)\r\n\r\n")
   end)
      
   conn:on("disconnection", function(conn, payload) print(' \nDisconnected') end)
           
   conn:connect(80, host)
   
   -- release connection objects
   conn = nil
   payload = nil
   --host = nil
   --param = nil

end
-- First reading data
ReadBMP()
-- Periodic reading of the sensor
tmr.alarm(1,300000,1, function()ReadBMP()end)

I had a lot of logic issues as I went along, then ran into memory issues which forced me to refactor (which in and of itself wasn't necessarily bad - I drove some efficiency into my programming).

The next step is to set this up outdoors and let it roll for a day or to. Then I need to figure out how to insert a time stamp (Adafruit's IO site doesn't calculate it for you). Once I'm done with that in Lua, I'll build the same functionality in Arduino and see how much better it runs.

Thursday, March 17, 2016

Pi vs Arduino vs NodeMCU vs ???

It's official - the Internet of Things has a lot of, um... things. So many options! Consider this: my friend and I are working on a weather station. Of course, it can't just be a simple weather station, it eventually needs to be a cluster of stations that can be used to measure differences in micro-climates. More on that later, LOL.

The initial goal is to put a weather station on a roof, without wires. With so many little devices, the question is simple: which is the right device for the job?

  • I started in on this the other day when I started messing around with the GPIO pins on the Pi. In about 10 min, I was reading in temp and barometric pressure data and thought "Dang, that's easy!". The Pi is awfully powerful and, now with the Pi 3, wifi-enabled.
  • And then there's NodeMCU. Very cool little wifi-enabled device that can take signal on a variety of analog, digital and serial-dedicated pins. And then it can run Lua to actually form that data into "IoT" capable packages, like HTML pages or JSON packets. Finally, it can be a rudimentary http server, so data can be retrieved (conversely it could be written as a client, to push data directly into the cloud). Seemed to me to be the perfect solution.
  • My friend Chuck is a strong advocate for using the Pi with an Arduino on a Pi alamode board. The arduino collects the data, the alamode board pushes that data into the Pi, and the Pi processes it.
My take? I see four viable solutions for getting the data off the Sparkfun weather shield and into "a consuming sink" such as the cloud, a data aggregator like a database, or published to the web.
  1. Weathershield to Pi via GPIO interface
  2. Weathershield to Pi via Arduino
  3. Weathershield to NodeMCU
  4. Weathershield to Arduino with WiFi chip
Each solution has advantages and disadvantages, and that's what we're doing to explore now.

Weather Shield to Pi via GPIO

This is an elegant solution - it requires the Weather Shield, some connecting wires, and a Raspberry Pi. It's elegant in that there are few moving parts - wire it up, good to go. Right? Wrong. Not all of the Weather Shield components seem to have Python libraries available, which means the coding would need to be done in C. Not impossible, but not necessarily straightforward.



Acquisition cost: 
  • Weather Shield: $39.95 + shipping
  • Raspberry Pi 3: $35.95 + shipping
  • Misc parts: $5
  • Total: $80
Development effort:
  • Moderate to high

Weather Shield to Pi via Arduino

This is the easiest solution to build, frankly. The weather shield runs great on the Arduino, all sorts of libraries and sample code abound on the Internet. 

Acquisition cost:
  • Weather Shield: $39.95 + shipping
  • Raspberry Pi 3: $35.95 + shipping
  • Raspberry Pi Alameda: $35.00 + shipping
  • Misc parts: $5
  • Total: $115 + shipping

Weather Shield to NodeMCU

By far the most elegant solution, holy cow... Suspend disbelief briefly and take a walk with me... You have a weather station on the roof, which feeds data into a Sparkfun weather shield. That shield, in turn, feeds data into a NodeMCU chip - tiny, quarter-size chip with wifi on it. The NodeMCU does three things: 1) it pushes the data to a cloud service, every N minutes; 2) it serves the data up via JSON string to anyone on the local network, and 3) it serves up data via formatted HTML on the local network. Awfully cool, and the cost? Nominal.



What's the issue? Simple - the libraries for the components of the weather shield only exist in part, and it's a process of porting them to Lua to make them work. The other problem: NodeMCU only has a single analog pin, whereas the weather board uses three or four.

--> Caveat: the NodeMCU *can* be programmed via Arduino, using Arduino libraries. I need to look into this more; not sure if there's enough memory to do it, though. And the Arduino environment has convoluted support for outputting HTML. I think I just need an afternoon to figure it out though. But still, the bottom line is it's not the right tool for this job.

Acquisition cost:
  • Weather Shield: $39.95 + shipping
  • NodeMCU: $15.00 + shipping
  • Total: $55 + shipping

Weather Shield to Arduino with Wifi Chip

This solution is honestly just a variant on the above solution - the weather shield speaks to an Arduino (great library support) and the Arduino uses a Wifi chip on a shield to publish the data. 

Slightly more expensive than the standalone NodeMCU solution:
  • Weather Shield: $39.95 + shipping
  • Arduino Uno $24.95 + shipping
  • Ada fruit Huzzah wireless shield: $39.95 plus shipping
  • Total: $105 + shipping

Summary

The cheapest possible solution, using the Weather Shield with NodeMCU, is not possible because NodeMCU only has a single analog pin and the weather shield needs multiple. That doesn't mean NodeMCU isn't a useful tool - I have a couple of other projects it might be perfect for. It does mean, however, that it's the wrong tool for this job.

From a financial perspective, the lowest cost solution is the Weather Shield plus the Raspberry Pi. It presents some problems - probably not insurmountable, but there'll be some effort to integrate the Weather Shield natively into Pi via Python or C. The time spent may not be worth the money saved over the alternatives (which both make use of an Arduino to read and interpret results).

So a little research is needed, to see how well the Pi can work with the Weather Shield's components. That's how to solve this specific application, but making a global rule overall? Globally I think it's easy to say that the NodeMCU is a low-cost solution but will almost alway have a steep implementation curve, at least until the dev community matures and catches up with Arduino. Overall from a sheer convenience perspective, the best solution is either 1) Arduino with Pi or 2) Arduino with wireless.

Bottom line: my buddy Chuck is right. When I insisted I take some time to look into building this solution with something other than Arduino, he told me I was wasting my time. I *was* right in that it would be more elegant, but he is right from a practical perspective. Everything is just "there" and ready to use, if Arduino plays a role in the solution.

Wednesday, March 16, 2016

NodeMCU for the Absolute Beginner - Lessons Learned

About a year ago, a buddy of mine who knew I was really into Raspberry Pi and Arduino encouraged me to look into NodeMCU. It's an IoT hardware platform with an onboard Wifi chip as well as a linux-based OS which is programmable in Lua. I messed around with it long enough to see it connect to the web and download a test page from Adafruit, but honestly? I was starting my own business and absolutely swamped.

Fast forward a year. A long year. A year of almost no hacking - Arduino, Pi, nothing... On a whim, I broke out my Pi and started messing with the GPIO interface and soon had a BMP085 sensor connected to a Python script, writing temp data into a csv file. Pretty cool! Not included to quit while I'm ahead, and finding myself waiting on a couple of clients (and therefore with some 'flexible' time), I decided to break out the NodeMCU. Turns out, someone had gotten the BMP085 working on NodeMCU. After several hours across a couple of days, and running into a steep learning curve, I finally got my BMP085 working on NodeMCU as well!

NodeMCU - This Ain't a Piece of Pi (or Arduino)

OK so you want to jump aboard the IoT craze and get involved. You're familiar with Arduino but you want something lighter, faster, and network enabled. That fancy NodeMCU dev board has been calling you, right?

All in all, it's a nifty idea and it works well (once you get past the learning curve). But if you're coming in from Visual Studio, from Xcode or even from Arduino Studio, be warned: this is not a polished experience. In fact, it's pretty ugly and dirty. Lots of flashing, formatting, serial communications await you before you actually have a working application. It is definitely not for the faint of heart, but if you persist, you'll get there.

Not a Tutorial

This article isn't a tutorial, per say, but a collection of things I picked up over the past few days. Really, there are 3-4 'gotchas' that I'm going to document. There are plenty of tutorials out there, but many of them skip over the 'what the heck do I do now' scenarios. Hopefully I can fill in the gap for you a bit:
  • Flashing can be tricky. Use Windows.
  • Establish a serial connection as the Node device powers up, so you can see any error messages.
  • Debugging is a pain - you need to check for messages as soon as the device boots.

Flashing

I did most of my work on my Raspberry Pi--not really sure why except that it's a throw-away environment where I'm always in screen or minicom, so I wasn't overly concerned about messing things up, and I had all the tools I needed. It might be faster to work elsewhere (I'm running a Pi 3 B+ so it's actually not heinous). There's even a fancy flashing tool (esptool) available for Linux. However... don't do it. I ran into a really weird issue where I saw symptoms like:
  • Device showed up online, but worked 'wonky'
  • I could program it in Arduino studio with the NodeMCU plug in
  • I could not connect to it on Linux over serial comm, unless I tried 115200, but even then things were just weird.
I tried refreshing it with the esptool, which appeared to succeed, but which in the end actually failed.

The answer? Use the Windows flasher tool to flash the build. I spent a good 2 hours one evening digging around trying everything I could think of and finally powered up a Windows machine, flashed it and <poof> everything worked great.

Don't. Seriously, just don't flash it on Linux. Use Windows. It's worth the time you'll save.

Establish Serial Quickly

When the NodeMCU powers up, it very quickly spits some diagnostics to the serial port. It's important that you catch those diagnostics, to be sure you see any messages that might crop up, oh, if your code has a syntax error or such. There is NO INTELLISENSE and NO DEBUGGING on this platform. If you write a mistake, you're not going to catch it any other way besides 1) manual code review or 2) catching the Node as it boots. So be quick on the "screen /dev/ttyUSB0 9600" command, as soon as that device boots.

Debugging

I said it above, but... I created a web page to serve up my inside temp information. I had some syntax errors on the page (not surprising, since I was editing in Leafpad and had some rather convoluted HTML code). I tried three ways from Sunday to get the thing to run. I rebooted it 15 times, but each time I tried to connect, Safari or Android Chrome responded with a connection reset error. I could ping the device (and get responses), but it just wouldn't serve a page.

So then I remembered my point about establishing serial quickly. The next time I powered up, I opened up a serial console ASAP and sure enough - the device spat out some error message about malformed HTML. Fixed it and I was good to go, but I lost a couple hours on this.

Conclusion

I see a lot of great uses for the NodeMCU devices. Remote weather stations no longer need wires. You can put moisture sensors in the far corners of your damp basement. I'm even planning to use one for model rocket telemetry information. It's really a clever device, and the Lua language is rather fun to use. This is going to be a fun device in my arsenal. Keep an eye, by the way, at my other blog securitygeezer.blogspot.comsecuritygeezer.blogspot.com because I have a feeling the NodeMCU device is going to come in handy on penetration tests and such.

Tuesday, March 15, 2016

Lost your Raspberry Pi Password?

I dug out my old Raspberry Pi "WarPi" gear today, as it was high time for a refresh. And of course, then it hit me... I forgot the password. What to do? I have hours into this device building Kismet (fixing a double conversion issue), hooking up the GPS, etc.

Well never fear - my buddy Chuck helped me through it. It's a snap:

  1. Pull the SD card
  2. Mount it somewhere else (I use a Mac, but you can mount it on Windows or Linux or what have you)
  3. Open the "cmdline.txt" file
  4. Add "init=/bin/sh" to the end of the FIRST line. 
  5. Save "cmdline.txt" again, unmount/eject the SD card and reboot the Pi
  6. When you get to the command prompt, type "mount -rw -o remount /"
  7. Next, type passwd pi and reset your password
  8. Next, type sync
  9. Then exec /sbin/init
  10. Finally, reboot (you can use sudo halt)
Now log in as usual.

Saturday, January 23, 2016

Sena SMH10R

Let's begin by way of explanation... I live in Utah. Almost everything is built on a grid square - it's one of the great things the pioneers did. Every major city settled by Mormons has a church building of some sort as its center--Salt Lake City's building is an LDS temple whereas many other cities were "centered" around a tabernacle - a large building (much larger than a standard congregational building). From there, streets were numbered in 100's for every block north, south, east or west. So someone who lived on, say, 52 South 400 East lived on the street 400 East, about a half a block south of the central building's cross-road. And 400 East runs north-to-south.

Confused? No matter - it's not the subject of this blog.

Not all of Utah is a snap to follow. For instance, who knew there was a Naples, UT--or a Bluff? Who knows how to get to Hovenweep National Monument (without a map)? I'm often fumbling for directions and I like to drive (and ride) as distraction free as possible, so I usually have Google Maps running (my car is 12 years old - fantastic sound system and a good navigation system, but the maps are old and missing a lot of more recent roads - my house, for instance, is not on a 'digitized road' as the navigation system likes to remind me). It's all the more important to me on the bike that I have good directions readily available. This is one reason I bought a Sena SMH10R Bluetooth headset.
 
 And I kid you not, I swear this thing is more complicated than the Space Shuttle... It has more options for pairing with other headsets, Bluetooth-enabled devices, etc. (there is even a Sena device that will connect to and control a two-way radio).

When I purchased my Sena, it connected with my Nexus 5x phone without any issue. Music was playing right off the bat, but I couldn't get turn-by-turn directions to play through the Sena device. Nor could I get it to work when I also connected my Nexus 7 tablet (which I intend to mount in the windscreen, just about the instruments, so maps are readily visible).

Some experimenting led me to the solution:
  1. Connected the Nexus 5x
  2. Went into settings for the Sena SMH10R bluetooth connection
  3. Enabled everything
  4. Went into settings for Google Maps
  5. Selected "Play Voice over Bluetooth"
  6. Shut down the device
  7. Powered back up
  8. Connected to the Sena SMH10R
  9. Bingo - turn-by-turn through the Sena

Next, I connected my Nexus 7 tablet (which is also running the latest Android OS). The first time I did it, I connected it as a multi-point device as per page 15 of the Sena owner's manual. I could never get turn-by-turn directions to come through the headset, though. Finally, I deleted the Sena device in the tablet's Bluetooth connection panel, then put the Sena into phone connect mode (not multi-point mode), and then connected. Once I enabled "Play Voice over Bluetooth" in Google maps, I was happily hearing maps through the Sena device again.

So, recapping
  1. Connect to the Nexus 5x phone as above
  2. Put the Sena into phone connect mode (first option in the Configuration menu)
  3. Connect the Nexus 7 tablet
  4. Go into Bluetooth connections and enable the Sena Bluetooth connection for everything
  5. In Google Maps' settings, enable "Play Voice over Bluetooth" 
Away you go...

Having trouble following that? No worries. This is the current Bluetooth connection settings dialog on Android OS:

And this is the options dialog for Google Maps:
 
Some people worry about the distraction of having a GPS connected to your helmet, but it's honestly not distracting. Having Google tell me well in advance where to turn, and in which direction, is actually quite settling. The voice is not intrusive, I can still hear traffic (if I'm not wearing ear plugs), and I'm not panicking trying to make a quick right across a lane of traffic. I call that safe.

Now - an electronic tablet will NEVER replace a good map--and I will always have a map with me. When I'm deep in the backroads, I'll also have an independent, battery-operated GPS unit to use with my map. The tablet's nice, but it's no guarantee. Nothing can replace good route-finding skills, especially the further you get from civilization.

The Sena offers 7 DAYS of 'standby' time (time where you're not talking), and 10 HOURS of talk time (which is great if you're paired with another rider in intercom mode). 

Tuesday, January 19, 2016

This is big... Crusher in the Tushar

So apparently the mind is a terribly weak thing, quick to forget the negative and prone to amplifying the positive. After a mediocre 2012 ride in the "Crusher in the Tushar," and a miserable 2013 ride during which I vowed never to return, for some reason I eagerly signed up again for the 2016 race.

This ride is, well, a little bit nuts. 70 miles. About 35 of those are on gravel (the rest is pavement--of which a lot is slurry seal). By mile 23, we will have gained 5000 vertical feet and passed 10,000 feet in elevation. From there it's a quick descent where we will lose all 5000 feet. But don't worry. After slogging through what seems like miles of sandy trail, we climb that 5000 feet again, averaging 8% and at some point hitting a 16% grade. And the suffering isn't over yet--a quick drop, some rolling hills and another long slog up are the reward. If we haven't given up yet, there's a roller coaster ride down and then a super-steep ascent to the finish line.

Here is the web site http://www.tusharcrusher.com and here is a map of the course:


The first year, it took 8:18 minutes to finish. I smiled the entire way, in spite of my almost dead-last performance. I had signed up to prove to myself that I can do really difficult things. I was just starting the training process, competing in a few triathlons but never rally riding enough to prep me for 70 brutal miles. Still I enjoyed the experience.

The next year found me very distracted, having fixed up a house, moved, and gotten married. I was miserable on the ride that year. Very little training, overweight, and simply dog-tired. It was hot and the hill was steeper. In 2012, I had at least done a few major hill climbs. In '13, I think I did 3.

So far, it has been different this year. I'm on the trainer at least 3x a week. My schedule is lighter so I can get in more training rides. I'm building a 26'er with a triple crank, which won't make me go faster but at least I can spin my way up even the 16% grade. I'm dropping weight (already at least 10 pounds lighter than in '13) and building !muscle and endurance. Above all, I am learning a lot about my fitness, peak output levels, etc. My goal is a 7:30. I'll blog on occasion about my rides, training progress, etc.