Wednesday, May 16, 2018

Update: Getting Status Data from a Huawei E8372 USB Dongle

In my previous post, I describe a script for getting the status from a Huawei dongle. Since I wrote that, I have improved the script that I wrote. Here is the updated script:

#!/bin/bash

#Status: http://hi.link/api/monitoring/status (GET)
#    ConnectionStatus:
#        112 = no autoconnect
#        113 = no autoconnect on roaming
#        114 = no reconnect
#        115 = no reconnect on roaming
#        900 = connecting
#        901 = connected
#        902 = disconnected
#        903 = disconnecting
#
#                   |    discon      |      con      |
#                   |   2G   |   3G  |   2G  |   3G  |
#      NetworkType: |   3    |   4   |   3   |  4/7  |
#      3 = 2G / 4 = 3G (UMTS) / 7 = 3G+ (HSDPA)
#
#    SignalStrength: strength in percent
#
#    ServiceStatus: 1 = enter PIN / 2 = PIN correct
#    SimStatus: 0 = no SIM access / 1 = SIM acc

site='192.168.8.1'

element_ses='response/SesInfo'
element_tok='response/TokInfo'
element_connstat='response/ConnectionStatus'
element_networktype='response/CurrentNetworkType'
element_sigicon='response/SignalIcon'
element_wanip='response/WanIPAddress'

url="http://${site}/api/webserver/SesTokInfo"

xml=$(curl -k --silent -X GET "$url")

#echo "$xml"

COOKIE=$(printf '%s\n' "$xml" | xmlstarlet sel -t -v "$element_ses")
TOKEN=$(printf '%s\n' "$xml" | xmlstarlet sel -t -v "$element_tok")

#echo "$COOKIE"
#echo "$TOKEN"

monit_url="http://${site}/api/monitoring/status"
device_url="http://${site}/api/device/basic_information"


MODEMSTATE=$(curl -k --silent -X GET "$monit_url" -H "Cookie: $COOKIE" -H "__RequestVerificationToken: $TOKEN" -H "Content-Type: text/xml")
#curl -k --silent -X GET "$url" -H "Cookie: $COOKIE" -H "__RequestVerificationToken: $TOKEN" -H "Content-Type: text/xml"

#echo "$MODEMSTATE"

CONNSTAT=$(printf '%s\n' "$MODEMSTATE" | xmlstarlet sel -t -v "$element_connstat")
NETWORKTYPE=$(printf '%s\n' "$MODEMSTATE" | xmlstarlet sel -t -v "$element_networktype")
WANIP=$(printf '%s\n' "$MODEMSTATE" | xmlstarlet sel -t -v "$element_wanip")
SIGICON=$(printf '%s\n' "$MODEMSTATE" | xmlstarlet sel -t -v "$element_sigicon")

echo "Connection State: $CONNSTAT"
echo "    Network Type: $NETWORKTYPE"
echo "     Signal Icon: $SIGICON"
echo "          WAN IP: $WANIP" 

This script works better than the old one and lets you return just the information you want. Note, in my script I return the signal strength icon because the Signal Strength value seems to always be null for this dongle. You can tell relative strength by the signal strength icon. Here is some sample output. I have since gotten a dongle that is compatible with T-Mobile networks in the USA, so the network type is 19 - I guess that means LTE since that is what the dongle's website says when I connect to it and look at the network type. Note, I replaced my IP with x's

pi@remotepi:~/modemwork $ ./get-modem-state
Connection State: 901
    Network Type: 19
     Signal Icon: 1
          WAN IP: xx.xxx.xxx.xxx 

In order to really interact with the dongle, I needed to be able to login to the web site that the dongle provides. To do that, I had to move to using a library that was written by someone else. I will make a new blog post to describe how I use it to do more with the dongle, including getting and sending SMS messages!

Wednesday, March 7, 2018

Getting Status Data from a Huawei E8372 USB Dongle

I am working on creating a remote solar-powered station that will report weather data from a location in Canada using a cellular connection. At the heart of it will be a Raspberry Pi Zero W running in headless mode. It connects to the weather station and then will send the data to the Weather Underground over the internet. The location is on a pretty remote island; it is just withing cell coverage, but with no commercial services at all, particularly no power. The location is occupied much of the time in summer, but during the winter - from about October until May there will be no one at the location at all.

This presents a number of problems for a system that has to function without any local interaction; there will be no one to power cycle the devices, look to see if any lights are lit, and there will be no one to push a reset button if that is needed. The entire system has to be setup so that it can do these things and act autonomously to recover from all sorts of situations that might arise. For instance, after the snow falls, the solar panel may get covered and stop producing power; weather may also cause it to lose connection to the cellular internet.

This means adding some smarts to the system to detect when these states might happen. To those ends, I have purchased a current and voltage monitor board, a solar charge controller, a real time clock module and a USB extension board for the Zero. For cellular connectivity, I will be using a link to the T-Mobile coverage in Canada - on the island it is limited to 3G, but since the data being transmitted is simple weather data, it should work fine.

Monday, October 3, 2016

Canada and Flashlights

This past Summer we took a trip back up to the vacation home of my brother-in-law's family. It is not really a home but an entire island. Before they bought it many years ago it was a fishing camp. It is located up in the Georgian Bay close to the town of Killarney. They have spent every Summer going up and enjoying the utter beauty and tranquility as well as improving it as they went along. I have been up several times over the years and, in my opinion, it is one of the most beautiful places on the earth. I dearly love it there. The stunning beauty, incredible weather, pure water and star strewn night sky are hard to describe for anyone who has not been there.

A photo from the island from 2007

Part of the allure for me is that it is rustic. There is no commercial power to the island so when you are there you need to have a few critical tools with you. A pocket knife, a lighter and a flashlight are standard. You just always seem to need those with you. Since I am bit of an excessive when it comes to flashlights, this is just fine with me. I love little flashlights, and big flashlights, and ones that flash and one that do not, I love lanterns and spot lights, too. Which brings me to the point of this post.

A few years ago, I recommended to my neighbor, a US Navy SEAL, that he participate in a Kickstarter program for a custom made programmable flashlight called a HexBright. He put down his money and waited a pretty long time before the product became a reality. When he received his light, I was immediately jealous, it was a very cool; solidly built, rechargeable, very bright and long lasting.



But best of all, it is programmable! It is not a simple mode and level type programming; it is fully programmable, built around an Arduino board with an on-board accelerometer and high power LED drive circuit. I have been programming micro-controllers for a very long time, so this thing was perfect for me. I wanted one of these little guys very much, but the cost was nearly $100! That is lot of money for a flashlight, but I came into some found money, I think I won a gift card at a meeting and then I took all my loose change and cashed it out and it totaled just enough to get one. It is my absolute favorite tech tools. It is heavy duty, waterproof, self-contained and works perfectly. After I received it I began working on programming it right away. I was able to take an excellent existing program called "Up and Down" and improve it. With the program I made for it, it has capabilities far beyond the reach of any normal flashlight.

Tuesday, January 12, 2016

Printed PCB for RC Telemetry Bluetooth Interface

This is an extension of the previous post.

I have been toying with the idea of putting together a control system for my smokers. It involves sensing temperatures and controlling a fan and doing some display. Pretty simple stuff for a Teensy or Arduino, but when it comes to uploading that data to the internet, those platforms fall a little short. That is where a Rasperry Pi shines. So the idea is to make a board that mounts on a Pi and is able to communicate with it, as well as do the control stuff. This is very similar to DIY controller called the "Heater Meter" (link to the store). This is going to be a very complicated board, but I thought that using the technique of leveraging a Teensy, like I do with the RC Interface would make sense. While doing the research on the Heater Meter, I found that they have their boards fabricated by OSH Park. OSH Park grew out of a club that assembled small pcb boards into a single panel and then had that made by a fabrication house. That is another story told better on their website, and not mine to tell, But the best part of it all is that OSH Park can make 3 copies of your board for $5 per square inch. That is a fantastic price and you usually only have to wait 2-4 weeks to get your board back. For my board below that ended up being about $22 or about $7.33 each. So why does this matter for the RC Telemetry Interface? Well, I figured that I needed some practice using the software that is used to create the schematic and design the board and I also wanted to see how the whole process worked, so I thought I would use the RC Telemetry Interface to learn how it all worked.

The software I used is the free version of CAD Soft Eagle, so I set out to learn it and to create the schematic and board for the interface and here are the results.

The circuit is as described in the previous post, but I added two buttons, and LCD screen and an LED. Here is the schematic.
Schematic for the RC Telemetry Interface

Pretty simple really, but the fun part is when you switch to designing the board. Even with the simple schematic shown above, the board gets pretty complex. This is the version 1.2 of the schematic and board; the boards pictured below are from the first version and there are some differences.

The picture below is the layout of the board, and what might not be apparent is that the blue lines are on the back side and the red lines are on the front. Also, all the parts are actually mounted on the front, this means that the LCD panel will mount on top of the Bluetooth module and the Teensy. I did this to protect the Teensy's program button, In the first version, I put the Teensy on the back, but the "program" button kept getting pressed when it is set on a table. This solves this problem and makes for a compact package. In addition, having the Bluetooth module on the front under the LCD allows me to see the blinking light that indicates the state of the module. You can not see it directly, but the flashing light is pretty easy to see around the LCD.

You can see that I have the two buttons positioned below the LCD and an indicator LED as well since it might be hard to see the Teensy's LED. I also placed the SPECTRA interface on the top, so it is easy to see if it is plugged in or not. Last, I have added a plug and an on/off switch that allows the unit to be powered from a LiPo battery. The plug fits the batteries available from Adafruit.

Board layout for  RC Telemetry Interface


Here are pictures (front and back) of the board that I had made from OSH Park:



And here are some pictures of the first version with the parts attached. Note, I placed the Teensy and the LCD using headers so that I could remove them for testing and debugging. Also, I made a mistake in the schematic for the Bluetooth module, getting the Rx and Tx lines not connected properly, so you can see that I had to use wires to connect it, this is fixed in the new version.






If there is interest I can post the Eagle files or point you at the projects on OSH Park's website.

Matt

Wednesday, May 20, 2015

Spectra Module to Bluetooth Link for RC Telemetry

The Android App I created, "RC Telemetry", will display the telemetry received from a Hitec Spectra Radio system. Unfortunately, to receive that data directly from the aircraft you would need Hitec's proprietary radio receiver and creating something like that is just too hard. Fortunately, there is another way to receive the telemetry data, and that is by receiving it from the Hitec Spectra module in your transmitter itself. The telemetry data is sent back to the Spectra module from the aircraft and if you are using a Hitec Aurora radio system, the data is then sent on in to the radio and is displayed on the control panel. If you are using just the module inside a different radio, then you can still get at the telemetry data, but you have to access it by connecting to the Spectra module. The Aurora radio receives the telemetry data over a low level protocol called I2C and we can use it to to get access to the data.  In that protocol, there are "Slaves" and "Masters" and they refer to the roles that the devices play when communicating. In the Hitec system the Spectra module is the "Master" and sends data out to all "Slaves" on the bus. In order to start receiving the data, we have to connect a device and have it become a "Slave" to the Spectra module.

Once you have connected to the I2C bus and set about becoming a "Slave" you will start receiving data like any other "Slave" on the bus. So in order to get the Android App the telemetry data, we need to create a little hardware device that will connect to the Spectra module receive the data and transmit it on to the Android App. The easiest way to transmit the data to the Android App is to send it over a Bluetooth Serial link, and that is just how the App is coded.

Here is how the data flows through the system:
Spectra <- (I2C) ->Teensy (Serial Data)->Bluetooth Module (2,4GHz radio) -> RC Telemetry App

The following is my description of how I assembled a device that does what is described above. I experimented on a breadboard, but I will be soldering this together to make a little unit to connect to my radio all the time. I will include picture of that in a different post.

I have recreated this device using three different micro controller boards: Adafruit Trinket, Teensy 2.0 and the Teensy LC. Of these three boards, I really prefer the Teensy LC because it is so much fast than the other boards, so you can do much more with it. In fact, I have added a little Nokia LCD display to the device so I can display real time telemetry right on the LCD screen without the need to even have the app running.

Components

  1. Microcontroller board:
       Teensy 2.0, running at 3V3 - $16 for board and $1 for the 3V3 regulator
       Teensy LC running at 3V3 -  $11.65
       Adafruit Trinket 3.3V - $6.95
  2. Bluetooth Serial Module - $6.27 from DX.com
  3. Standard Servo Cable (3 conductor, keyed)
  4. 2 1.5K Resistors to use as pull ups

Wiring


Bluetooth

The pins of the TeensyLC and Bluetooth modules have names and are marked on the devices. We will be using the TeensyLC's hardware serial port, so we must use the specified pins. Here is the connection matrix:

Teensy to Bluetooth
TeensyLC pictured


 Teensy 2.0  TeensyLC  Bluetooth 
GND
GND
GND
VCC
VCC
VCC
D2
0
TxD
D3
1
RxD



Spectra

The Spectra module has a port in it where a standard Servo connector can be connected. It might be covered by a small plastic cover, We will number the port from the top to the bottom. The top is the connection closest to the keyed port. In the photo the yellow line is connected at the top:

Spectra to Teensy
Spectra Module with Servo Cable




 Spectra 
 TeensyLC 
 Teensy 2.0 
1 (yellow) 
19
D0
2 (red)
18
D1
3 (black)
GND
GND












In order to connect the servo connector to the Teensy, I used 3 pins plugged into the servo cable and that plugged into breadboard. The 1.5k resistors can be seen plugged from the pins to the 3.3V bus. These must be present to in order to pull up the I2C bus:
TeensyLC pictured with Pull ups

Testing

Plug in your Teensy at this time, it should power up and the Bluetooth module should power up as well. On the both the Teensy and the Bluetooth module there are LEDs that light up, if you do not see any lights, unplug it and check your connections.
When the Bluetooth module gets power, you will be able to bind it to your computer or your phone. It will not get any data yet, of course, but you should see it out there. After you bind to it and connect, the blinking light will change to steady on.

Programming

Install Arduino and Teensyduino in order to program the module using the Arduino interface. The program for the TeensyLC version of the program depends on the i2c_t3 library, so make sure that you install that library when given the choice while installing Teensyduino.

Note, For the Teensy 2.0, I am running it at 3V3 and at that voltage, it is supposed to only run at 8MHz; I run it at 16MHz and there do not appear to be any ill effects. On the TeensyLC, this is no issue, it is a 32 bit processor running at 48MHz at 3V3!

I have written a simple program that will configure the micro-controller to be a slave on the I2C bus so that it will receive data from the Spectra module. As soon as it receives a packet of data, it immediately transmits that data out to the Bluetooth module. This program is dumb, it does not even look to see if there is a valid Bluetooth connection or anything, it just sends the data. It does have some code in there to blink the LED on the board when it is receiving data and to glow steady if no data is being received.

TeensyLC

The TeensyLC version of the program does not take any special modification to the library it uses, so just download the program and load it up in the Arduino environment and program the Teensy LC with it.

Spectra_to_TeensyLC

Teensy 2.0

The program for the Teensy 2.0 depends on a modified version of the Wire library called WSWire. This modification has a set of loops that will reset the I2C hardware on the Teensy if the bus gets locked up. Be sure that you install the WSWire library, I provide a link here, but I think you can find it elsewhere too. To install the library, follow the directions on the Arduino website, there are instructions on how to install a library there.

WSWire Library

Download the Arduino program below and program it onto your Teensy, it should start running immediately

Spectra_to_Teensy20

-Matt-

Thursday, November 20, 2014

Connecting a Raspberry Pi to the Anova Precision Cooker

I backed a Kickstarter campaign to bring a new version of a cooker that allows a home cook to use the "sous vide" method of cooking just like fancy restaurants. The device is priced far below commercial units available, but performs exceptionally well. This new device is the Anova Precision Cooker and can be ordered here. This device sports a Bluetooth interface so that you could program and monitor the unit from a Bluetooth enabled device. Being a geek and software developer, I opted to support at the "Hacker" level which gave me early access to a prototype unit so I could work on developing an app or other software for the device.

I also recently purchased a Raspberry Pi B+ from Sparkfun.com and had been tinkering with all sorts of things on it. As a side note, I also purchased a cool Plexiglas enclosure from Adafruit industries, I highly recommend it, she makes them on site and it is a perfect fit and looks cool. The Pi is a great little platform and can do all kinds of things big computers can do at a fraction of the price. Currently I have it interfacing to my weather station and posting the weather data from my backyard up to the Weather Underground, I thought it might make a good platform to interface to the Anova as well; this brings me to the point of this post. 

Once I got the idea of interfacing to the Anova unit from my Raspberry Pi, I did a little research and found I needed to purchase a Bluetooth dongle that would be compatible with the Anova. Since the Anova uses Bluetooth LE, the dongle must also support that and I needed one that had already been successfully interfaced with the Raspberry Pi (no need to re-invent the wheel here). The one I chose is based on the Cambridge Silicon Radio and I got it from DX.com from their USA warehouse: ultra-mini-bluetooth-csr-4-0-usb-dongle-adapter.

So with the Pi, dongle and the Anova unit in place, it was time to see if I could interface them. My research found an awesome resource on eLinux.org on how to get Bluetooth LE working on a Raspberry Pi and I followed this almost exactly to get my Pi to talk to the Anova. Here is the blog post: http://www.elinux.org/RPi_Bluetooth_LE. The following pictures correspond to particular steps in the posting and I have tried to reference each of them for the pictures.

I followed all the steps up to the "First Test" header in the posting to get the proper software installed, configured and working on my Pi.Next I followed the instructions and the picture below are my results when following them.

Results of "lsusb" with the CSR BT Dongle plugged in
Doing a detailed "lsusb" on the CSR BT Dongle

Results of the detailed "lsusb"
Results of the "hciconfig"
Bringing the CSR BT Dongle "up"
Results of the "hcitool lescan" command
Results of the "hcitool lecc" command
Now the posting deals with accessing the Bluetooth device from using Python. I followed the instructions to build "bluepy" on my machine and then issued the command as described in the posting. My results follow and show that the software was able to connect to and identify the Service and Characteristic that is used to send commands to the Anova.

Results of running "btle.py"
That's it for now, the next step is to take the btle.py Python code and update it to send a command to the Anova. This is simply done by writing to the Characteristic with its value set to a recognized command (status, read temp nn, write temp nn, etc.).

 -Matt-