GPS on SIM7600G-H 4G HAT (B) for Raspberry Pi

I bought this device from Amazon to use for a project with a Raspberry Pi Zero and a data sim from my Google Fi Account where I wanted network connectivity. The fact that it had GPS as well was a bonus.

I installed gpsd on raspian. (apt install gpsd gpsd-clients -y) It didn’t automatically recognize the GPS. I was able to get it working by modifying /etc/default/gpsd to have the line DEVICES=”/dev/ttyUSB1″ and then starting the GPS with the command echo AT+CGPS=1 >/dev/ttyUSB2

After that combination, running gpsmon or cgps returned results after the GPS had been able to achieve a fix.

vi /etc/default/gpsd
echo AT+CGPS=1
lsusb -t

I’ve still not got it automatically starting the GPS with the echo command and am working to figure the best place to have that command.

SIM7600G-H 4G HAT (B) for Raspberry Pi, LTE Cat-4 4G / 3G / 2G Support, GNSS Positioning, Global Band
SKU: 19485
Part Number: SIM7600G-H 4G HAT (B)
Brand: Waveshare

Raspberry Pi GPSD with Pepwave MAX Transit

I’ve been wanting to do some GPS data programming with the Raspberry Pi that’s on my boat. The Pi is connected to the NMEA 2000 network, and so should be able to retrieve GPS coordinates from either my chartplotter or my AIS unit when they are powered on, but it should also be able to get the GPS data from my Max Transit cellular gateway device.

It turns out that configuring gpsd to retrieve the data from the max transit was fairly easy. I edited the file /etc/default/gpsd to include the internal address and port of my router and restarted gpsd and now the Pi has the correct location.


The devices section was initially empty. I added tcp:// between the pair of double quotes. After that, I was able to run gpsmon with no parameters and it connects to the local machine and reports the gps statistics.


I’d verified that I can read the device directly over the network with the command gpsmon but I wanted to be able to write my programs without needing to know where the gps was located.


New B&G Zeus™ 3S 9

This week I replaced my old Garmin GPSMAP® 740 with a brand new B&G Zeus™ 3S 9 chartplotter with C-MAP cartography. I’m excited about using this because I’ve used older B&G Zeus products on friends boats and this has everything I’m used to with more processor speed.

I had earlier upgraded to communication in my boat to connect the older Raymarine Seatalk instruments to the NMEA 2000 network using a Raymarine SeaTalk1 to SeaTalkng converter kit (Part Number E22158) with a blue DeviceNet adapter connecting to my NMEA 2000 backbone, and a white DeviceNet adapter connecting to my Garmin GPSMap 740. This allowed my garmin to show a few more details and my raspberry pi to capture and log the data from the depth and wind instruments.

I was hoping that beyond the physical changes to my instrument pod with the installation of the new B&G unit, the wiring changes would just require disconnecting the Garmin from the NMEA2000 connection and connecting the B&G to the same connection.

I did that. Then when I powered on the B&G, it asked for confirmation to discover all connected devices, which I had it do. It wasn’t seeing the results from the raymarine devices on the network, though it was getting AIS targets from the Garmin AIS 300 receiver and seeing my new fusion radio, both on the NMEA2000 bus. The communication path to either of those units was via the Seatalk converter, so I was confused as to if the B&G couldn’t see the old instruments, and spent a couple of days looking for possible solutions.

Most of the solutions I seemed to run across made me think that there may be too much power loss on the length of NMEA2000 backbone cable reaching from inside nav station to my outside pedestal. When I’d originally installed the converter kit, I spliced in power in the pedestal. Power was supplied directly to the converter, and it provided power to the NMEA2k backbone. During my installation of the B&G I attempted to do some wiring cleanup. I removed the power to the converter, and provided power to the NMEA2k bus in the nav station.

Here are several links to discussion that suggest power across the length of the backbone may be my problem:

I took video of the status led blinking on the converter, and it never was reporting low voltage. It was definitely reporting something with data, but I wasn’t sure if it was the first or second from the list.

I wasn’t excited about cutting and splicing my pedestal power connection again to provide power directly to the converter, and while playing around and power cycling everything, I realized that if I power cycled the converter/nmea2k bus, and brought up the B&G and just looked at the instruments, the converter was visible in the B&G!

If I selected it, I could see all the data it was publishing from the instruments on the NMEA2k bus.

That seemed like success! (The Sea Temperature reading has been whacky since I’ve bought the boat, and I can’t seem to figure out how to get it to read the correct temperature on the original ST60+ Tridata either.) So I told the B&G to auto select it’s data sources again.

After doing that, the Seatalk converter no longer was visible in the list of devices, or the data it was publishing. I also figured out that my Raspberry Pi stopped logging the data from the instruments when this happened. (I’m pretty sure my raspberry pi is the device at the top of the device list with — under both Model ID and Serial No. Fixing that is a low priority task for me. If you know how to properly configure the Pi please leave a comment pointing out what I should do. This is the platform I’m running.)

After several tests, I figured out that my Raymarine instruments continue working and putting data on the NMEA2k bus as long as I don’t have the B&G auto discover sources. I manually went through and configured the sources in the B&G settings, and was able to get things configured as I want.

I’m not 100% satisfied because I don’t think I should be able to take the converter offline with whatever commands the B&G is sending over the NMEA2k bus, but I’m happy that I didn’t have to splice more cables this week.

DJI Phantom and Wind

This week I took my drone to video Initial Point in Idaho. It’s a rocky outcrop about 20 miles south of Boise that was chosen as the initial survey point for the Idaho Territory in 1867. It has a concrete platform installed at the top with a survey marker embedded. There’s a rocky trail that can be driven to the top if your vehicle has a high ground clearance. I chose to walk to the top.


Initial Point Idaho

My car was parked at the base, I climbed up about 130 feet to the top. The wind was occasionally gusting at the base. It was constant at the top, with much higher gusts.

I carried the drone in my backpack to the top, and launched it from the platform. I manually flew it around the point, but was feeling extremely nervous doing so. I only flew about 36 feet above the platform during the entire flight.

The concrete platform has a metal railing surrounding it, and I didn’t trust the drone to return safely to land without hitting the railing so I manually had it land nearby. As I was hovering the drone before landing, it was holding a fairly constant 20° lean because of the wind.

After hiking back to my car I still had plenty of battery for another flight. From near my car I launched the drone and flew vertically to about 200 feet, centered the drone over the survey marker, and used the point of interest feature to create a video circling the point.

I don’t believe that the wind was any less on my second flight than it was on my first flight. The fact that I was in the wind on the first flight had me feeling significantly more nervous while flying than when I was out of the wind on the second flight. Watching the video from the first and second flight doesn’t appear significantly different. I would have liked the point of interest video slightly more if I’d been on top of the point the entire time, but I was too nervous to do it all while I was sitting in the wind myself.

FrSky X4rSB Receiver controlling Eachine Racer 250

I wanted to use S.Bus communication to connect my receiver to my new Eachine 250 
Racer drone. I wanted to be able to remotely control the lights on the drone. I wanted to bring back telemetry from the drone to my transmitter. All of those are possible with the X series receivers from FrSky.


I’ve used the X8R receivers in the past, but I bought an X4R-SB receiver specifically for this drone.

In it’s default configuration it will output PWM on the pins for Channels 1 through 3 and S.Bus on the 4th connector. It has a separate input connection on the side for S.Port telemetry devices and an analog data line.

By putting a jumper on the signal pins, as shown in the picture above, during the binding process, the output is changed so that CPPM channels 1-8 are on the first port, PWM Channel 9 and 10 on the second and third ports, and S.Bus on the fourth port.

I’ve got the S.Bus connection going to the main port on my CC3D flight controller, a cable to control the lights on the third port (channel 10) and the first two ports remain unused. I have the momentary switch SH on my Taranis configured to control Channel 10. Toggling it cycles the LEDs on my Eachine Racer through the  off and on colored states.

The telemetry cable is connected first to a FrSky SP-GPS – Smart Port GPS Sensor (GPS-V2) and daisy chain connected to a FrSky SP-FLVS – Smart Port Lipo Voltage Sensor.


The GPS Sensor is a new item in my arsenal. I’ve used GPS chips connected to my flight controllers in the past, which allow the flight controller to direct its flight position using GPS. Since this is not connected into the flight controller, it’s purely a toy, though it may help finding the drone if I get confused and crash it away from myself. The last data received in my transmitter remains on the display, which I could then use to assist my search for the drone.

The voltage sensor connects to the balance plug on the battery, allowing me to monitor the state of the individual battery cells during flight, as well as having low battery alerts reported on the overall voltage.

For installation of this receiver in my drone, I’d come across a 3d model for a holder. I had never used a 3d printer before, though I’ve been fascinated with them for several years. I realized that Windows 10 has a 3d Modeling program installed by default, 3D Builder, and that it can print using an on-line service.  Because the service accepts the file and tells you how much it is going to cost delivered, this was an easy first try. I downloaded files for both a battery protector tray and the previously mentioned receiver tray, merged them into a single model file, and had them delivered for $27.15. Other than the time involved for the delivery I was happy with the result. I submitted the order on 4/26/2016. I received notice that it shipped on 5/10/2016. It finally arrived on 5/13/2016.


The design here has the receiver extending in the model over the flight controller and under the video transmitter. I’m not positive that I’m going to use the battery tray. If I don’t use it, I just need to get screw extenders to install the receiver directly above the flight controller.

Nikon D5300 and GPS

I purchased a Nikon D5300 as an upgrade to my old Nikon D60 about two months ago. A major selling point of the D5300 for me was the built in GPS with the ability to add geotagging data to my pictures. I understand that it may take some amount of time for the camera to attain GPS lock after it’s been turned on but I’ve been seriously disappointed in the performance in this case.

During the two months I’ve had it I was not able to get it to acquire GPS data once. I regularly walk south along the Seattle waterfront as part of my daily commute, a little over half an hours walk. I tried multiple times to leave the camera turned on for the entire walk with the camera hung around my neck sitting at my stomach. but it never managed to do anything but blink the satellite indicator on thew screen.

Finally this last week, I went and downloaded a copy of the A-GPS Update File from the Nikon Web site. After doing that, and starting a GPS Logging operation at the beginning of my walk south, the camera was able to report GPS position for the first time. Even after it was in logging mode and reporting GPS position for some of the pictures, it wouldn’t maintain them for all of the pictures in a sequence of pictures.

The data file that I downloaded is supposedly only good for less than a month, and even then only two weeks at a time, so to make this useful, it appears that I’ll have to get new downloads from Nikon at least once a month.

I believe the GPS antenna is not mounted in the highest portion of the camera. There’s a flat portion of the case between the main control selector dial and the case strap that has the GPS symbol as well as the WiFi.

Because I don’t have an android phone or iPhone I find the WiFi connectivity feature useless. I can’t connect it to my local network at home or work and control the camera from a device on my local network. I would have to disconnect my ipad from my local network and connect it to my camera, which means that I have no advantage in using my camera to shoot pictures to social networking sites.

I like the camera for its resolution and low light sensitivity, just am disappointed in the wireless features.

Near Loss in Tall Grass

UAV completely hidden in the tall grass

UAV completely hidden in the tall grass

This weekend I went out with a friend to fly my quadcopter UAV.  It had been several weeks since I started working on the lighting project for my UAV and I’d not had opportunity to do any flying since. I still don’t have the lighting relaying the control board status, but I do have the new lights installed, with both of the right arms wrapped in green and both of the left arms wrapped in red.

I’ve been flying the Ardupilot firmware 3.0.1 since I put the APM into my quadcopter. In general I’ve been happy with the solution, but I’ve had problems with it’s loiter function and sometimes return to launch causes the copter to take off in odd directions. I do not have the optical flow sensor installed on my unit and so the loiter function is purely based on GPS signals.

I’ve been reading the release notes on the release candidates for the Ardupilot firmware 3.1 and decided that since I didn’t know why my 3.0.1 copter wasn’t flying well, I might as well live dangerously and see if the 3.1rc4 did any better.

I checked the box in Mission Planner that I wanted to use the beta software, it refreshed itself and offered to let me load the 3.1rc4 firmware. After doing that, I went through the initial setup and calibration of the compass, accelerometer, and throttle settings. Then we went to try to fly the copter.

Initially things seemed very good. The new firmware rotates the motors when they are armed, which is a nice safety and status indication. The takeoff seemed smoother than most of my takeoffs have been, with the initial trim seeming to be perfect. I could release the right stick entirely and the copter was hovering in place with throttle control alone. Changing the switch to loiter mode also had it holding in the right position.

Problems seemed to happen after about five to seven minutes of flying. The return to launch and loiter functions seemed to become significantly less stable with erratic horizontal movements.

During the first flight with the new firmware after several minutes of comfortable flying I put the controller into loiter mode and handed the transmitter to Brett so he could see how it flew. I noticed that I’d obviously not configured the firmware to correctly monitor the battery power because Mission Planner was reporting 0.00v. Things continued well for a couple of minutes but then he started to have problems controlling it, RTL was not bringing it back towards us, and loiter was not causing it to hold position. He told me that he was making the decision to land where he was in the field and I confirmed that was the best thing to do. I have no problem walking a distance through a field to find a copter, but would not want to lose the copter in the trees.

Mission Planner Display of Flight

Mission Planner Display of Flight

Measuring some of the distances using the ruler in Google Earth show my copter was 160 meters away from us at the farthest southwest point, and only 20 meters from the trees. When Brett set it down, it was about 120 meters from where we were standing. We were flying visually, I have no cameras installed on my UAV right now.

I thought I knew where the copter had gone down, and so told Brett to stand in place and I’d go retrieve it. After walking a large distance and not seeing any sign of the device I turned around to see if Brett could point me in the right direction. He pointed me in one direction but I was still not having any luck. Communication was made worse because I’d left my phone back where we were flying from and was now standing over 150 meters away.

I realized that carrying the transmitter would have been a good idea because I could arm the motors and possibly hear them thrashing the grass, or even attempt to take off the unit to be able to zero in on it’s location. I went back and retrieved the transmitter, and Brett decided he could assist me from the air with his HexCopter. He’s set up with First Person Video and also has a GoPro Hero3+ Black on a brush-less gymbal mount. He was confident that he’d be able to quickly find my brightly lit QuadCopter from the air.

I went back out walking around the field, and he soon joined me virtually via his UAV. The video of our searching is on youtube. It was an overcast day and the grass had never lost the moisture the morning fog left it coated with. It’s possible to see the tracks where I walked because of the darkness where the grass has been disturbed.

After all of the manual searching, we were not able to find the copter. Starting up my computer again I was able to reestablish communication with the copter and read it’s reported GPS coordinates.  Brett entered the coordinates into an app on his iPhone and it took us to within 15 feet of the device and I was able to find it by the noise of the rotors attempting to move the grass when I tried to raise the throttle. The grass was thick enough that my motors would still not spin, and not much noise was made.  Even standing and looking down on the unit, it was easy to lose it in the grass.

I have overlayed the Brett’s search path and my flight path in Google Earth and it appears that he never went exactly over the top of the copter. Here are two different angles on the complete flight profiles.

Path of two UAVs with an overhead perspective

Path of two UAVs with an overhead perspective

Path of two UAVs showing the elevation

Path of two UAVs showing the elevation perspective

The path of my UAV switches colors each time the mode is switched between flight modes. I have configured Stabilize, Loiter, and Return to Launch. The relative horizontal speed of travel is indicated by the distance between the points on each line. Closer points indicate slower movement. Brett’s search path generally moves slowly and all of the points are close together. He nearly exhausted his battery in approximately 8 minutes of searching.

I have spent a lot of time sailing and one of the things leaned is a proper man overboard drill. During a proper man overboard drill it is one person’s responsibility to do nothing but keep pointing at the person overboard. Holding an arm outstretched pointing makes it much easier to keep track of exactly where the person is. To someone who has never done a drill it seems like it would be easy to keep track of a person or relocate them, but it is not. Losing a UAV in a field is not the life and death situation that losing a person overboard in cold water may be, but it is a reminder that you should have a plan for proper recovery when things go wrong.

I should have:

  • Read the GPS coordinates from the ground station immediately after the UAV landed.
  • Had Brett point at the location the device disappeared into the grass.
  • Carried a communication device into the field with me so that Brett could have relayed directions to me without shouting across over 100 meters.
  • Carried the transmitter with me on my initial trip to recover the UAV.

Considering that nothing was lost but time, it was a good day of flying.

UAV and GPS Dependency

Last weekend I was attempting to have my UAV fly a couple of programmed missions so that I could get a straightforward video of what I was doing.

My mission was simple, and I’d run similar missions before so I expected this to produce a nice video. I would take off, fly a circle with a 50 meter radius at 100 meters altitude, move to another location and fly a second circle at 30 meters altitude, then return to launch. Here’s what it looked like in Mission Planner.

Things look good in Mission Planner

Things look good in Mission Planner

Things started well, but went haywire a few minutes into the flight. There were a few bobbles as is descended from the first circle altitude to the second circle, but I was hoping to let the on-board computer maintain or recover control.

The flight starts around 1:40 on the video, and things generally look good until around 4:50. At that point the UAV starts making some significant attitude adjustments. Around 5:10 it seems to have recovered and making the adjustments to go around the second circle. (At 5:35 the camera is pointed back towards the launch point and you can see two small dots on the ground. That’s the two of us monitoring the flight with the transmitter and a pair of binoculars.) It finishes the second circle around 6:30, at which it should have initiated the RTL, Return to Launch, phase of its mission. Unfortunately I do not currently have the UAV set to face forward during the RTL phase, and so it does not rotate towards the launch point, just travels in that direction. You can see it tilt slightly back, moving in the correct direction, for the first ten seconds until 6:42, but then it starts making huge adjustments to its direction, running the motors at full throttle. At 8:08 it hit the trees.
After the flight I downloaded the log file from the UAV and tried to analyse what went wrong. I was able to produce this picture using Google Earth from the resulting KMZ file.

Mission Gone Bad

Mission Gone Bad

I’m still not sure exactly what went wrong. I believe that the copter lost resolution on the GPS, simply based on the fact that the track never shows it going to the trees, and I don’t remember it doing as much spiraling as the KMZ would indicate. The KMZ file may be available at my home server but right now it does not appear to want to serve kmz or kml files.  The descent from the first circle towards the second circle appears smooth until it no longer needed to travel horizontally, At the point when it needed to only reduce altitude it seemed to circle and appeared to be much more unstable. Perhaps making sure that all programmed descents had much more vertical motion would produce smoother flights in general.

A few valuable lessons that I learned, in no particular order.

  • Stick to flying where there are no people nearby. Even at an RC airplane field with a few experienced people around, this could cause significant injury to humans or damage to property. When the copter was coming in fast towards the landing area, and obviously going to overshoot into the trees, completely losing the copter in the trees is much better than causing any injury or damage to someone else.
  • Be quicker to abort an automated mission and take manual control. I had handed my transmitter to a more experienced pilot while I monitored the automatic mission via binoculars. Several times he asked if he should take control of the unit and I told him that I wanted to see if the unit would recover itself. The early bobbles during the descent from the first circle to the second it recovered, but the RTL path was completely wrong.
  • Give the UAV plenty of time to achieve a reliable GPS lock before arming the motors and taking off.  According to what I’ve read, the launch location used for the RTL function is stored when you arm the motors, not when you actually leave the ground, or power on the entire copter. Landing and disarming the motors in a second location would reset the launch location when you re-arm them.

An interesting thing I’ve noticed by following the drone chatter on the hype meter is how much of a clash this is causing between the computer and robotics crowd and the traditional RC airplane crowd.

The traditional RC airplane hobbyists have been around for over 50 years, and have slowly been integrating new technology such has digital radios, electric motors, and Lithium Polymer batteries into use as the technology as become available. Historical fixed wing aircraft and analog transmitters required large open spaces for both safety and to make sure that there was no radio interference. Liquid fueled model aircraft produced large amounts of noise, and so added to the reasons of working in large open spaces.

The person coming into the UAV/Drone space often has no background in the RC airplane hobby itself and so has no history of the safety requirements and why they exist. Starting with a quadcopter and its capabilities is completely different from starting with a fixed wing aircraft. VTOL, vertical takeoff and landing, brings a confidence that this can be done in a small space, however misplaced that confidence may be. First person video (FPV) seems a natural extension to most new pilots and the concept of limited bandwidth is completely alien.

There are good organizations such as that exist for hobbyists, but the person getting into it from the computer side of things often may not even know about them, and an unattractive web site may cause lack of understanding of the benefits offered.

I would not have gotten into this at all if a friend that I’ve known since we were in 4th grade had not added multi rotor copters to his long standing hobby of RC Airplanes. He was telling me how much was available in the new systems, and showing me first person videos on his screen. The fact that he was using all of these digital systems, but his video was still analog, was what got me interested. I wanted to be able to record the entire flight digitally.

I’ve been extremely lucky so far, not having damaged anything or injured anyone, and not broken more than $30 worth of items on my ‘copter so far, let alone lost it entirely. I’ve still got plenty to learn, as well as learning to be much safer, but I’m enjoying the process so far.