Thread Tools
Old Oct 18, 2015, 11:02 AM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Discussion
Long distance DRF1278F LoRa Lost model tracker

Inspired by the work done by srnet, I decided to create my own version of a lost model tracker based on a SX1278 LoRa module. My philosophy is a bit different (and much more experimental), so I decided to create my own Tx/Rx combo, as an excuse to learn. You can see my initial ramblings here http://www.rcgroups.com/forums/showthread.php?t=2453263

I call my tracker the ďeBay LoRa trackerĒ. I purposely designed it to only use components you can buy off of eBay, and I looked for the cheapest possible options, and so that itís easy to source all components no matter where you live in the world. Itís work in progress, shared freely, and has no implied guarantee.

It can be freely re-shared, but not used for commercial purposes

It uses a 3.3V, 8MHz Arduino Pro Mini (please note that I discovered that there are different variations of the Pro Mini, and the one I use has the FTDI pins flipped compared to the Arduino reference design. If you use a board that complies with the Arduino layout, it will not work on the PCB), a DRF1278 (LoRa modem from Dorji, slightly cheaper and easier to find worldwide than the RFM98), a LiPo charger module as a way to provide power and charge a backup LiPo (1s), and a uBlox M7- or M8-based GPS module. I need an uBlox module since I use a polling function to gather GPS position, more reliable than the default NMEA strings.

The board only uses a few extra components (2 LEDs, 4 resistors, a switch), and they can all be omitted. Total cost as of today is ~$20 , plus the PCB ($11.25 including shipping worldwide for 3 PCBs if you use OSHpark, the cheapest option for a small run: I designed the board to be the smallest/cheapest possible). If you build 3 units, the cost per unit is around $20, including the PCB.

I designed it to be easy-ish to hand solder (0805 components), but in order to get good solder joints for the Arduino and the modules you need a good temperature controlled soldering iron and some experience soldering)

A few caveats:
  • The board works in my tests. Iím not sure if yours will work as well as mine
  • The power supply is a weird design: the board can use a 5V-8V supply (usually 5V from your receiver) to feed a LiPo charger, with a backup battery. The backup battery is charged by the main power supply, with the LiPo charger providing power both to the board and to keep the battery charged. The Arduino reads the main power supply thru a voltage divider (since we use a 3.3V Arduino, canít read 5V-8V directly), and if the main voltage disappears, the Arduino can get into low power mode (more later). I powered the board thru the LiPo charger even without a backup battery, and everything works (since the Arduino draws enough current and the on-board voltage regulator handles any voltage variations). But Iím pretty sure no sane electronic engineer will design a power section like mine (even if I saw it used in other devices)
  • The eBay LiPo charger module usually is designed to charge a 1A Lithium battery. You can use it as it is, if you use a big enough backup battery (at least 750 mAh). Or you can use it as it is if you use a backup battery that is fully charged (since the charger will only trickle charge it, safely). If you use a small (say, Hubsan X4), uncharged battery, though, that charger will charge the battery at 1A, i.e. at 3C, and that risks damaging it over time. I replaced the resistor used to define the charge current with a bigger one, to reduce the charging current. The LiPo module I use is based on a TP4056 (https://dlnmh9ip6v2uc.cloudfront.net...ing/TP4056.pdf) and I used a 5.1K resistor (you need a 0603, even if a 0805 can be squeezed in) for ~250mA charge, safe for any battery. The downside is that it will take longer to charge. If you use a Li-Ion 18650 battery as a backup battery, the charger as it is will work just fine. With a bigger backup battery you will also have much longer standby times (but heavier)
  • If you plan to use Dupont-style pin headers on the board (2.54mm/0.1Ē), you need to remove the micro USB port from the LiPo module. Or you can use JST connectors with a short cable like I do, no need to remove the USB port

I will periodically update the first few posts, and add a link to the end of the thread with more info on the updates
robca is offline Find More Posts by robca
Last edited by robca; Oct 18, 2015 at 11:08 AM.
Reply With Quote
Sign up now
to remove ads between posts
Old Oct 18, 2015, 11:03 AM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Tx Hardware

Components list

Iím also planning to see if I can use this module instead http://www.goodluckbuy.com/vk1616u7g...na-1-10hz.html, much smaller and redesign the PCB to be even smaller. You can use that module even today, if you want, but will not make the tracker any smaller until the PCB is redesigned. Software-wise, they are all compatible. I fear that with the small antenna, though, it wonít be as good as an M8 module with a 25mm antenna.

You can use any uBlox-based GPS, as long as it has a serial port. Even older 6M units will work. Any APM GPS module you have around can be made to work, but will not fit on the PCB, all you need is to make sure it uses 3.3V supply, and has serial Rx and Tx pins

In order to assemble the board, I added some kapton tape on the back of all the modules, just to be extra sure nothing shorts. But itís almost surely overkill, since the board (and all the modules I use) are well protected by solder masks. I did discover, though, that kapton tape helps prevent shorts under the Arduino board: if the Arduino and my PCB touch, solder can wick under the pads and cause a short (in one instance, D8 and D9 shorted, causing some pain to resolve.

I started by inserting a 2.54mm/0.1Ē header into the Arduino FTDI port, and pushing it down all the way so that the pins protrude from the other side of my PCB (pins easily slide in a header connector, if you push with the right force). That helps ensure that all the Arduino pins are properly aligned with all the soldering pads. I soldered the pins on both sides (the Arduino side, which I called the ďbottom sideĒ, and the PCB ďtopĒ side, where the GPs and LoRa module are). Itís critical that the Arduino makes good contact with those pins, since I rely on the VCC/GND connections thru the Arduino FTDI pins (it was much harder to layout the PCB otherwise). The downside is that the exposed part of the header connector is shallower than usual, but since itís only used to flash the Arduino once, itís an ok tradeoff for me)

If the Arduino is aligned correctly, solder all the pins by putting a fine tipped soldering iron thru the Arduino holes, adding a bit of solder with good flux, and moving the tip up and down a couple of times. The solder will flow and make a very good electrical/mechanical contact. Same process for the LiPo module. Then add the switch, resistors and power/battery wires to the bottom side (the bottom side is marked in the copper). Flip the board, add the LoRa module and remaining LEDs/resistors. The LoRa module is castellated and easy to solder. You can either add a 173mm wire as an antenna (quarter wave for 433MHz) or there should be enough space to solder a coax (signal and GND) connected to an SMA connector for a better antenna. Since 433 is used for telemetry and long range radios, plenty of choices there.

Lastly solder the GPS module wires, and use some dual sided tape of good quality to stick the GPS antenna on the PCB. The PCB is designed so that the GPS and LoRa modems are on top (in case you want to use a helical antenna on the LoRa module). If you use heat shrink around the unit, the resulting device is compact (2.03Ēx1.11Ē, 51.64x28.14 mm), and very sturdy. Without battery, it weighs 29g, with the GPS module alone being 13g

I tested the board and works well. I shared it on OSHpark, in case you want to order one for you. This is version 1.2, addressing some of the shortcomings of my first version (which, for reasons to long to explain, was 1.1). I used KiCAD, and I learned along the way (and I made a mistake in 1.1 of using 0805 pads for reflow ovens, the 1.2 version has the larger pads for hand soldering)
robca is offline Find More Posts by robca
Last edited by robca; Oct 19, 2015 at 06:15 AM.
Reply With Quote
Old Oct 18, 2015, 11:04 AM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Tx software

The Tx software should be fairly self-documenting, I used a ton of comments and as few programming shortcuts as possible. It still has quite a few Serial.print statements, to help troubleshoot any issue.

It programs the uBlox module to stop sending NMEA messages on the serial port used, and the code uses a polling technique to get data from the uBlox only when needed, maximizing reliability.

I rather heavily modified srnet's LoRa libraries, with proper credits (hopefully "proper")

Upon initialization it plays a 4-notes tune to let users with a radio receiver know it’s working. The idea is that the tracker will send both GPS data over LoRa and location tones (using srnet’s idea of playing different frequencies at different Tx levels to help locate the device when there’s no GPS lock). Any Baofeng radio can be used to listen to the tone and by using body blocking or other foxhunting techniques (http://www.k3dn.org/foxhunt.htm) to locate the lost model using only radio tones. Currently I have not implemented the code to send the tones (trivial to do, the primitives are there, I simply focused on the harder part of sending/receiving GPS location in an optimal way).

The code will also send failure tones if it can’t initialize the uBlox, and different tones upon first GPS lock, and first GPS lock with good enough HDOP (the idea being that you want to take off only after having reliable positioning data). The threshold of what makes for an acceptable HDOP is defined as a constant in the code, and can be optimized for your case

The default LoRa frequency is also defined as an easy to change constant. Currently I use a slow rate, to ensure maximum distance (cased on srnet’s tests). That makes the length of a packet significant

The code reads the UBX packet from the GPS module, stores it in a structure for later use. Periodically it sends a “short message”, 10 bytes long, containing Lat, Long and HDOP. Every 4 short messages, it sends a “long message”, 23 bytes long, containing all the GPS data. I assumed that a shorter message would go thru much faster than a longer one (roughly half the time), but the LoRa headers/footers and encoding must take quite a lot, since the “short message” takes roughly 3.5 seconds to send, while the “long message” 4.7 seconds. I wanted to keep the message as short as possible, in case you end up using a busy frequency (a strong signal on the same frequency in the middle of a LoRa packet can trigger a CRC error and discarding the packet), but I’m not sure it’s the right strategy… more though on this is needed.

In order to further optimize transmission times, I also send only “serialized binary data”. A full ASCII packet with all the captured data, would be ~70 bytes long. By sending the binary representation of the values (and in some cases compressing multiple values into a single variable), I can send the full data in only 23 bytes. I wrote a Serialize() and DeSerialize() function to handle the process (plus the “short versions”, SerializeLLH() and DeSerializeLLH() to only send Lat, Long and HDOP, the most critical pieces of data). There is a full explanation in the code on how each variable gets serialized. the only small downside is that converting lat/long into a float type in some cases introduces a small error due to the float encoding on the Arduino. In my tests, the error was never greater than a few cm, so not a problem given the GPS precision and the purpose of the locator (GPS location error is at least an order of magnitude greater than the error introduced by the conversion)

I use three types of packets (for now), one is a system message (not implemented yet), one for short messages, one for long messages. I do so by adding a byte to the LoRa packet, and processing it independently of the rest of the payload. More packet types can be easily added, for example to send error messages.

The board is designed to sense when it’s powered by the main model power supply (thru a 5V supply), and when it’s using battery. I plan to implement sooner or later a “low power mode” to enhance battery life (probably putting the uBlox in low power mode) and sending fewer packets to ensure longer backup battery life. Once the tracker has a good GPS lock and the position has not changed in, say, 10 minutes, the GPS can be safely put in low power mode and woken up only once every 30 minutes or so to check if anything changed. The GPS module is the most power-hungry component on the board. I might also implement a timer for extra confidence: if the locator has been on for longer than the timer max duration, it can be assumed that the model is lost. I do not use a PPM/PWM input to determine if the RC Rx is on, since I don’t see much value in relying on a failsafe signal to trigger the model lost mode (and it adds some complexity to the code)

For now, though, the locator only sends GPS information over and over again
robca is offline Find More Posts by robca
Last edited by robca; Oct 18, 2015 at 01:10 PM.
Reply With Quote
Old Oct 18, 2015, 11:04 AM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Rx hardware

I use another Arduino 3.3V, 8MHz, an identical Lora modem (DRF1278F) and a 5110 LCD, easy to find everywhere. All powered directly from a battery connected to the RAW input on the Arduino, and providing 3.3V to the LoRa module and 5110 LCD

For now, I have decided not to build a PCB, since the value of having a PCB is limited. It’s relatively easy to solder the few necessary wires to the LoRa module and 5110, and once it’s in a box, it’s as sturdy as a PCB (unlike the Tx, which can take some real abuse in a crash landing).

The connections are as follows (also documented in the code):

Arduino pins for LoRa DRF1278F

Arduino pin -> DRF1278F pin, Function
D6 -> 1 RESET
D7 -> 13 NSS
D11 -> 12 MOSI
D12 -> 11 MISO
D13 -> 10 SCK

Arduino pins for 5110 LCD
Arduino pin -> 5110 module
D8 -> 5 D/C
D9 -> 4 RESET
D10 -> 3 SCE
D11 -> 6 DN (MOSI)
D13 -> 7 SCLK
LED backlight connected to VCC with a resistor


The code (more below) will receive the LoRa packets deserialize them, and then build two NMEA sentences (GPRMC and GPGGA), sent via the Arduino serial. This way the receiver works as a standalone serial GPS module, sending all the necessary positioning data to any application that can accept NMEA data and display it on a map. By using an Android device with USB OTG, I can connect a serial adapter and use one of the many Android mapping applications that support external GPS. It’s also possible to connect a HC-05/06 Bluetooth module to the serial port of the Arduino, and send NMEA data via Bluetooth to any Android device. Obviously a PC/Windows tablet also works well, both with serial and Bluetooth. That allows you to track your model location in real time when flying (added benefit it’s that you can use the unit as a telemetry module) and easily find your model if lost.

I use the 5110 LCD to also show location and signal strength, so the unit can be used without a direct connection to a mapping device.
robca is offline Find More Posts by robca
Last edited by robca; Oct 18, 2015 at 12:49 PM.
Reply With Quote
Old Oct 18, 2015, 11:05 AM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Rx software

The receiver software, after initializing the LoRa modem for the same parameters as the Tx, starts listening to LoRa packets. I rather heavily modified srnet's LoRa libraries, with proper credits (hopefully "proper")

Iím using a fast 5110 library, with all credit in the library headers. I slightly tweaked them for my use. The libraries I use are surprisingly memory-effective, since they do not require a screen buffer (usually 504 bytes, 40% of the available space in an Arduino). That allows to use pretty complex code with no problems (when using more common libraries, more than once I started experiencing low memory issues, and random crashes)

The display shows an antenna icon (copied from the historic Nokia 5110 icon), flashing once per second (to let you know itís working), followed by the background noise signal (in dBm, even if I shortened it to dB to fit in the small screen) and, upon receiving a packet, the packet signal strength. You will notice that, when the packet is being received, the background noise shows much higher values than at rest, given that the LoRa module ďhearsĒ a signal in the frequency being monitored, and until the packet is fully received and decrypted it cannot know if itís a signal or background noise from another transmitter on the same frequency. If the packet is interrupted or disrupted by another signal, the first line briefly shows CRC error (CRC ERR), then loops again and keeps listening

On the second line, it shows how long (in seconds) the device has been listening without receiving a valid packet (it shows the age of the last received packet)

The receiver recognizes three packets: a system one (not implemented yet), the short packet containing only lat/long and HDOP, and a long packet with the full GPS data (for the logic, see the note in the Tx software above). Valid packets are deserialized into the same uBlox structure used by the Tx software, basically recreating an identical copy of the information (minus a small loss of precision due to float handling in the Arduino code)

Third line shows latitude, fourth shows longitude, all in standard format.

The last line shows the HDOP for the last lat/long pair (lower HDOP = better fix), followed by the number of satellites used for the fix (only if the device receives a long packet, once every 4 short) and a letter (S or L) showing if the last received packet was a short one or a long one.

At the same time, every time a packet is received, the receiver sends two NMEA messages over serial. The two messages contain all the necessary information for mapping software to track the position of your model. In the current implementation, latitude, longitude and HDOP are updated every time a short message is received, and the remaining fields are from the previous long message (the one with all the information). It works as expected, since the most relevant info is the position. As I said, Iím rethinking my short/long message approach, since it doesnít seem to save much and adds a bit of complexity

Here's a sample of the NMEA output (I replaced 2 of the Lat/Long digits and the checksum with xx, to avoid sharing my apartment location . You can see that the timestamp updates only every 4 messages

Note: as you can see, there's a problem in the NMEA strings, an extra space in the middle of the string... It's just a RcGroups issue: the output from my program is just fine, but somehow RcGroups adds a space after 50 characters, as you can see in the first line, which I typed as a single line of 60 characters, no space (and there's no space when I return to edit it)

12345678901234567890123456789012345678901234567890 1234567890

$GPRMC,115408.00,A,513x.x7600,N,0001x.x1322,W,0.24 4,0,191015,,,D*xB
$GPGGA,115408.00,513x.x7600,N,0001x.x1322,W,1,6,1. 45,109.389,M,0,M,,*xF
$GPRMC,115459.00,A,513x.x7650,N,0001x.x1383,W,0.59 ,0,191015,,,D*xF
$GPGGA,115459.00,513x.x7650,N,0001x.x1383,W,1,7,1. 45,100.636,M,0,M,,*xC
$GPRMC,115459.00,A,513x.x7740,N,0001x.x1377,W,0.59 ,0,191015,,,D*x4
$GPGGA,115459.00,513x.x7740,N,0001x.x1377,W,1,7,1. 45,100.636,M,0,M,,*x7
$GPRMC,115459.00,A,513x.x7790,N,0001x.x1242,W,0.59 ,0,191015,,,D*xE
$GPGGA,115459.00,513x.x7790,N,0001x.x1242,W,1,7,1. 45,100.636,M,0,M,,*xD
$GPRMC,115459.00,A,513x.x7840,N,0001x.x1213,W,0.59 ,0,191015,,,D*x8
$GPGGA,115459.00,513x.x7840,N,0001x.x1213,W,1,7,1. 45,100.636,M,0,M,,*xB
$GPRMC,115459.00,A,513x.x7840,N,0001x.x1218,W,0.59 ,0,191015,,,D*x3
$GPGGA,115459.00,513x.x7840,N,0001x.x1218,W,1,7,1. 45,100.636,M,0,M,,*x0
$GPRMC,115550.00,A,513x.x7840,N,0001x.x1352,W,0.25 3,0,191015,,,D*xC
$GPGGA,115550.00,513x.x7840,N,0001x.x1352,W,1,7,1. 45,105.717,M,0,M,,*x0
$GPRMC,115550.00,A,513x.x7740,N,0001x.x1386,W,0.25 3,0,191015,,,D*xA
$GPGGA,115550.00,513x.x7740,N,0001x.x1386,W,1,7,1. 45,105.717,M,0,M,,*x6
$GPRMC,115550.00,A,513x.x7650,N,0001x.x1330,W,0.25 3,0,191015,,,D*x7
$GPGGA,115550.00,513x.x7650,N,0001x.x1330,W,1,7,1. 45,105.717,M,0,M,,*xB
$GPRMC,115550.00,A,513x.x7700,N,0001x.x1317,W,0.25 3,0,191015,,,D*x6
$GPGGA,115550.00,513x.x7700,N,0001x.x1317,W,1,7,1. 45,105.717,M,0,M,,*xA
$GPRMC,115550.00,A,513x.x7740,N,0001x.x1300,W,0.25 3,0,191015,,,D*x4
$GPGGA,115550.00,513x.x7740,N,0001x.x1300,W,1,7,1. 42,105.717,M,0,M,,*xF


UPDATE Oct 21, 2015: Added HC-06 Bluetooth module, fixed compatibility issue in NMEA GGA message. New ZIP file replaces the old
robca is offline Find More Posts by robca
Last edited by robca; Oct 21, 2015 at 08:08 AM.
Reply With Quote
Old Oct 18, 2015, 11:05 AM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Connecting an HC-06 module to the Receiver and Android app

I bought a cheap HC-06 module from eBay (where else? ), and Iím using it to send NMEA data to GPS Rocket Locator, a great Android app that does exactly what we need https://play.google.com/store/apps/d....rocketlocator. You can find the description, screenshots and a link to a donate page here: http://rocketlocator.com/ (thanks to user gpsklaus for the initial suggestion, and thanks to Francois for developing such a great app and answering my questions). With this app, you can map your location, the location of your model, and easily find it (you can build a version of the receiver without the 5110 and just use this app, but the LCD is pretty helpful). One day I hope someone will write a custom app for the LoRa receiver (we can all dream ), and send all the relevant data to an Android app, requiring no LCD. But the 5110 is cheap enough not to be a problem for now.

There was a small incompatibility between my code and Rocket Locator, now fixed in the new version (shared above)

Please make sure you buy a HC-06, not the HC-05, since the HC-05 can be trickier to setup. Hereís the module I bought http://www.ebay.com/itm/HC-06-30ft-W...-/381374724434 There are also modules with a backplane, providing a step down voltage converter, resistors to protect the HC-06 inputs (not 5V tolerant) and a LED. Those are great if you use a 5V Arduino and want to breadboard prototypes. But we do not need the 5V -> 3.3V converter, nor the resistors, since the receiver is built around a 3.3V Arduino. The only component on that breadboard that is helpful is the LED used to show when the Bluetooth module is waiting for pairing or paired, but you can hack your own solution, and use an LED mounted in your box. In the picture enclosed you can see how I added the LED directly to the back of the module (0805 yellow LED, plus a 2k Ohm resistor). Iím also enclosing an image with the connections needed to make the module work. Iím using a 2k Ohm resistor, because thatís what the backplane uses, and a red or yellow LED (blue, white might need a smaller resistor). Iím guessing that the resistor is that big on the backplane to limit the current that the HC-06 must provideÖ usually a resistor for 3.3V would be much smaller. But 2kOhm works, so why not?

Iím using SoftSerial() to communicate with the HC-06, so that we can keep using the FTDI header to flash the Arduino and as a debugging port. Iím using D2 and D3, but as usual that is defined as a constant in the code

Most of the HC-06 come preconfigured as 9600, and the Bluetooth pin is 1234. If you want, you can change the name with a USB/Serial adapter, using AT+NAMEmodulename (I changed it on mine, now itís called LoRa_GPS), but you must use either a backplane to prevent burning the HC-06, or use a 3.3V supply, and a resistors on the RX pin of the HC-06 (to limit the voltage that the serial adapter sends), plus a pullup on the Tx pin (to ensure that the serial adapter can read the logic signals). There are plenty of tutorials online on how to do itÖ but the easiest way is to use the Arduino to do it for you, since you already have a 3.3V serial port. Iím enclosing a small Arduino program to just change the HC-06 name. You can use it with the receiver hardware, as long as the HC-06 is connected properly.
robca is offline Find More Posts by robca
Last edited by robca; Oct 21, 2015 at 08:14 AM.
Reply With Quote
Old Oct 18, 2015, 11:06 AM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
reserved.
robca is offline Find More Posts by robca
Reply With Quote
Old Oct 19, 2015, 03:24 AM
iskess is offline
Find More Posts by iskess
FPV in Hawaii
iskess's Avatar
United States, HI, Kailua
Joined Feb 2012
2,705 Posts
You have taken srnet's brilliant work and made it much more accessible to us mere mortals. Thank you! Could you post a video of it in action?
iskess is offline Find More Posts by iskess
Reply With Quote
Old Oct 19, 2015, 06:13 AM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Thanks for the nice words

I guess I could take a video, I'm just not sure what people would like to see in it, though. I'm going to post a screenshot of the 5110 LCD with the available info, and I assumed that would show all that matters...

If you send me a "script" of what you'd like to see, I'll be happy to post something the only caveat is that I'm currently living in London, and there's no flying here without going far out of town, and that's something I don't plan to do for a long time
robca is offline Find More Posts by robca
Reply With Quote
Old Oct 19, 2015, 10:55 AM
Rumcajs is offline
Find More Posts by Rumcajs
Registered User
Rumcajs's Avatar
Joined Jun 2012
66 Posts
I'm sorry, I use a translator ..
Is your system can work with GPS Crius CN-06 V3 U-blox ?
Rumcajs is offline Find More Posts by Rumcajs
Reply With Quote
Old Oct 19, 2015, 12:02 PM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Quote:
Originally Posted by Rumcajs View Post
I'm sorry, I use a translator ..
Is your system can work with GPS Crius CN-06 V3 U-blox ?
You could, but I would not recommend it.

In order to make it work, you will have to provide 3.3V directly to the Crius board. Can be done (you solder a 3.3V wire to the onboard 3.3V regulator), but you need to have good SMD soldering skills not to risk creating problems.

Also, that module is programmed to use 38400 bps on the serial port. You could ether change the module settings with uCenter, or change my code to initialize the port at 38400, send the configuration data, including the new serial port speed, then change the speed on the Arduino soft serial port.

And, after you do all this, you have only a uBlox 6 module, which is inferior to the uBlox 7 and much worse than the uBlox 8. Since the uBlox 7 costs ~$9 shipped anywhere in the world, and the uBlox 8 costs $12, shipped everywhere, there is little reason to use a bigger, heavier, worse GPS module

But, yeah, can be made to work if you know what you are doing...
robca is offline Find More Posts by robca
Reply With Quote
Old Oct 19, 2015, 12:28 PM
Rumcajs is offline
Find More Posts by Rumcajs
Registered User
Rumcajs's Avatar
Joined Jun 2012
66 Posts
Soldering'm not afraid - I just have a free and therefore I ask
Rumcajs is offline Find More Posts by Rumcajs
Reply With Quote
Old Oct 19, 2015, 12:48 PM
robca is offline
Find More Posts by robca
Registered User
United States, WA, Kirkland
Joined Sep 2013
1,484 Posts
Quote:
Originally Posted by Rumcajs View Post
Soldering'm not afraid - I just have a free and therefore I ask
Then go for it just remember to either change the serial port speed in uCenter (and save it), or change the speed of the serial communication in my code... since I use SoftSerial, I doubt that a 8MHz Arduino can handle 38400 bps in SoftSerial, so I recommend changing settings in uCenter (reset to factory settings, will work fine)
robca is offline Find More Posts by robca
Reply With Quote
Old Oct 19, 2015, 01:00 PM
Rumcajs is offline
Find More Posts by Rumcajs
Registered User
Rumcajs's Avatar
Joined Jun 2012
66 Posts
I know, but thank you for reminding me
Rumcajs is offline Find More Posts by Rumcajs
Reply With Quote
Old Oct 20, 2015, 03:18 AM
iskess is offline
Find More Posts by iskess
FPV in Hawaii
iskess's Avatar
United States, HI, Kailua
Joined Feb 2012
2,705 Posts
Quote:
Originally Posted by robca View Post
Thanks for the nice words

I guess I could take a video, I'm just not sure what people would like to see in it, though. I'm going to post a screenshot of the 5110 LCD with the available info, and I assumed that would show all that matters...

If you send me a "script" of what you'd like to see, I'll be happy to post something the only caveat is that I'm currently living in London, and there's no flying here without going far out of town, and that's something I don't plan to do for a long time
I was just hoping to get a better feel for the project and how it all fits together and functions. If a video is too time intensive, how about more photos showing close ups of the finished product. I would also like to see what the Rx side looks like in its box.
I have the soldering skills to handle a project like this, but I haven't done much arduino building. Perhaps I should let someone else do first.
I am looking forward to the foxhunting functionality to be added.


To save weight, can I share the GPS with my autopilot? I would use your PCB to power the GPS since it designed to remain powered after impact. The open space where the GPS usually could hold my battery.
iskess is offline Find More Posts by iskess
Reply With Quote


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion LoRa Ė Very Long Range Low Data Rate Telemetry. srnet DIY Electronics 40 May 26, 2016 04:12 PM
New Product Lost model locator || Distance-RC Beacon V2 Elmardus Flight Accessories 43 May 07, 2016 08:25 PM
Discussion Arduino LoRa Long Range Lost Model Tracker srnet DIY Electronics 102 Apr 01, 2016 01:05 PM
Discussion Lost Model Locator Tests - Long Range srnet DIY Electronics 17 Jul 10, 2015 11:32 AM
Discussion Lost Model Locator - with very long range telemetry capability srnet Flight Accessories 0 Jun 06, 2015 04:14 AM