$25 GPS Solution

ecarson said:

I re-verified that signal pulses are coming off the orange GPS wire. Nothing from blue wire while in normal operation. This is a screen shot from
the oscilloscope. I finally got the square wave edges well defined. I had wanted an oscilloscope since 1969, and finally got one earlier this year.
Hantek DSO5202P. It will take me years to learn all the stuff this thing can do, so waiting 48 freaking years was not so bad.

View attachment 326807

Click to expand...

Which means this image is incorrect?



I pulled that image off the net when I originally wired everything up. Here is another that I just now found:

https://ttstoreusa.guphotos.com/i/w?u=/images/R/6/RM7666/RM7666-1-1c9c-FdZ8.jpg

All wiring images I have seen online agree with each other. I don't recall which color was which or having a problem in the beginning as I opened my GPS case, de-soldered everything and made my own connections immediately after one test. The GPS board itself is marked tx, rx, v, g.

Perhaps the indications in the images correspond to the connection points on a flight controller board. I would have to splice another set I haven't touched yet to try to recall if I had to reverse tx and rx to get data. I have a faint memory of the initial test and think it may absolutely be possible I had to reverse them to get data.

Danh said:

is there a reason your frequency's are not the same on both settings?

Click to expand...

Don't read into the image. It is not my image and I don't even know what the field values are. That's just a screen shot I pulled off of google. It's purpose was to illustrate the "upload firmware" and "copy to remote" buttons.

Kurt,

Use a 1S lipo and power up the GPS unit alone (not wired to a radio). Do this outside and wait a few minutes. If you have a solid red, you have power. If you have solid red and then a blue blinking, you have satellites and your GPS is fine.

I would suggest truncating your messages and/or bullet pointing them. A clearer, more concise explanation would help me to better understand your situation.

CORZERO said:

Which means this image is incorrect?

View attachment 326808

I pulled that image off the net when I originally wired everything up. Here is another that I just now found:

https://ttstoreusa.guphotos.com/i/w?u=/images/R/6/RM7666/RM7666-1-1c9c-FdZ8.jpg

All wiring images I have seen online agree with each other. I don't recall which color was which or having a problem in the beginning as I opened my GPS case, de-soldered everything and made my own connections immediately after one test. The GPS board itself is marked tx, rx, v, g.

Perhaps the indications in the images correspond to the connection points on a flight controller board. I would have to splice another set I haven't touched yet to try to recall if I had to reverse tx and rx to get data. I have a faint memory of the initial test and think it may absolutely be possible I had to reverse them to get data.

Click to expand...

I guess it is matter of relative perspective on the nomenclature. Even on the AliExpress link from the first post, it indicates "connection orange to RX and blue to TX". This is what I did in the beginning, and nothing happened. So, I found that I had to connect the orange to the radio TX and blue to the radio RX. This worked. But when I first used the FTDI cable, it was again reversed. I assumed the radio transmitter label was not right. After all, GPS TX to radio RX, and GPS RX to radio TX makes sense. At that point, I made diagrams for my notebook showing what goes where. So now I know that the orange wire is what is putting out the pulses of GPS packets. Proof in the voltage pudding. Yet the orange GPS wire must go to the transmitter point labeled "TX" for anything to work! If I think about this too long, I get a headache. My primary goal is to be able to find a possible lost rocket on the ground, and so far this will fit the bill.

A secondary goal is being able to put my HAM call sign into those GPS packets, but that will require a programmable GPS module. Hopefully the one I ordered will be here in a few days.

CORZERO said:

"Upload Firmware" updates and reprograms the radios to the newest firmware version. Click "Copy to Remote" to program transmitter. See buttons below.

View attachment 326806

I highly doubt you have damaged any of your components. I have yet to experience any of the issues you mention, but I'll be sure and post my experience and solution if I do.

Click to expand...

The GPS I consider "disposable". The problem is I forgot what settings the v1 air module/tracker was. I reprogrammed the v1 receive unit to work with a v2 transceiver/tracker. Different net ID, frequencies
etc. So now I want both the v1 receiver and v1 remote/tracker back to "stock". Problem is, I forgot the v1 remote tracker settings. One can pair a v1 receiver with a v2 transceiver
with no problem. There is no USB port on the v1 remote/tracker to program from. It can only go out via the RF link and if the v1 radios aren't paired in the first place with the same
parameters, one is screwed. You forget to "copy required to remote" and then reprogram the receiver for another tracker, you won't be able to pair with tracker #1 unless you
remembered the parameters to "restore" the receiver to.

I plug in the "local" v1 receiver into the computer and either programmer will call up its settings. The trouble is the v1 "remote" doesn't give the solid green LED lock. Both receive and transmitter/remote have flashing green LEDs. I tried "flashing" but nothing happens to the remote. Only the local receiver is changed.

Tell you what, you program both the remote/tracker and the receiver and write down every parameter. Then plug in the receiver by itself and reprogram it with different frequencies and
network ID. It will work, only the receiver will come up and you can program away. Save it to the receiver only. Now turn on your remote/tracker and your receiver and you'll
get the flashing green LED of death. You can dink with it all you want. Flashing the receiver alone t'ain't going to work and the Rf link isn't going to carry the "new" firmware to the
tracker over Rf unless it's paired to start with.

I was hoping I'd be able to say, "You da' man." But unless there is way to bring back the two units to stock from the command line when they aren't paired with a solid green LED, I may have to go with an FTDI serial card and see if I can pull the data off the JST-SH socket (on the air module) and reprogram it to "stock" directly through the serial USB module.

I apologize for the wordiness but I've explored these units not knowing what I was doing and there is no other way to explain it. The original "OP" GPS chipset is scrambled and that's fine.
I have a couple more coming. Mixing them to different v1 and v2 radios got me into the bind when I "forgot" the original parameters of the v1 air module.

If you follow my instructions above, I suspect you will mess your units up as I did except you will have written down the instructions to reprogram your receiver/local module "back" to
match your remote/tracker.

Thanks for the help. The others posts have helped immensely. Especially the setup screens. I have no doubt that setting up a new rig will be successful as long as the steps are
followed exactly. Kurt

CORZERO said:

Kurt,

Use a 1S lipo and power up the GPS unit alone (not wired to a radio). Do this outside and wait a few minutes. If you have a solid red, you have power. If you have solid red and then a blue blinking, you have satellites and your GPS is fine.

I would suggest truncating your messages and/or bullet pointing them. A clearer, more concise explanation would help me to better understand your situation.

Click to expand...

The GPS protocols can get scrambled. Don't ask me how I know. I get a flashing blue and a solid red LED no matter what. I believe I dorked the GPS while programming a v2 transceiver with
the GPS attached. I have and FTDI USB/serial breakout board but I don't want to dink with it. Prefer to start fresh.
As far as restoring that air/remote v1 tracker, it's simply a matter of getting the baseline parameters input. For that, I think a USB/serial breakout board will do the trick so I can attach and download
what's in there now through that JST-SH four pin socket and then "restore" it to the default settings.

Unless you know a magic button to push to correct the dissimilar units I'm still all ears. Kurt

ksaves2 said:

I plug in the "local" v1 receiver into the computer and either programmer will call up its settings. The trouble is the v1 "remote" doesn't give the solid green LED lock. Both receive and transmitter/remote have flashing green LEDs. I tried "flashing" but nothing happens to the remote. Only the local receiver is changed.

Click to expand...

I take it that under the conditions you have described, even the "Reset to Defaults" button with both V1 units energized, does not have any effect?

ecarson said:

I take it that under the conditions you have described, even the "Reset to Defaults" button with both V1 units energized, does not have any effect?

Click to expand...

Nope. If there is no lock (solid green LED) it only resets the V1 receiver. The remote stays deaf. I found my 5V FTDI USB/serial breakout board in the garage. I just need to cobble together a cable and see if I can reset it through the JST-SH socket to get in business again. If I'm wrong on that point, anyone pipe in and I'll give any method a go.

Actually I'm glad this happened to me early so I could post it. With the cost being low if one had multiple trackers with different settings might be an issue if one reprograms a v1 receiver for another v1 tracker and forgets what settings they used.
True, you'll have a receiver for each tracker but mix 'n match as I did without recording the settings can get one in a bind.

The v2 3DR radio with the JST-SH and the micro USB socket is foolproof. Can connect to the computer and reprogram to default at will. The only problem with the v2 is one would make a nice OTG receive station but I don't think it's
amenable to being put in a rocket. Reason I came to that conclusion is that the "power in" comes from the micro USB socket and the +/- on the JST-SH socket is "power-out". I tried feeding 5V in through the JST-SH and I didn't get the
green LED. I saw a continuous red LED that is supposed to mean the v2 unit is awaiting a firmware upgrade. I did a cursory look on the USB socket and I couldn't find an easy solution to tap in for power. I didn't dwell on it as I was more
interested in getting a successful bench test pulled off.

I have no doubts that once I get the replacements, I'll be able to follow your instructions and get an operating system up and going. The Mission Planner screens posted here will give folks a starting point to go from. I didn't have that
earlier in the thread. Seeing the NMEA sentences coming off in the screen saves is encouraging to know the system works. A range test and real time flight data is going to be helpful as is the ability of investing in a GPS module that
will allow the Ham guys to put a callsign into the strings without messing up decoding. The thing I'm looking for is improving the real time recovery of positions for live map plotting. The current state of the NMEA tracker is that
one gets enough positions to get you into the ground footprint of the tracker but I'm am desiring a better live representation of the path during the flight. Quirky old me I guess. Yes I know there are logger boards and they are nice
but I'd like a little more detail while in the act of tracking. Why not since the cost of the technology has dropped significantly?

I'll mess with trying to recover the GPS and the v1 flight module later. I have the cable hardware to make a cable for the USB/serial breakout board for both. My goal is to get a successful bench test and then finalize the air module.

Since the specs call for 5V that's what I'm going to do. I bought a couple of these 5V 1amp regulators and am going to feed the radio and the GPS with this: https://www.pololu.com/product/2831.

Kurt

Ok,

Found this page that has an advanced discussion of the 3DR features: https://ardupilot.org/copter/docs/c...configuration-and-technical-information.html#

I scrolled down to the bottom and found the FTDI to USB cable to program the radios if the settings are lost. If one ends up like me, losing the settings on the "air module" of a v1 radio then
this is the page you need to go to. Also a large amount of programming information is there that might allow one to maximize range. That's what should be strived for. Kurt

Hokay,

I got my v1 Air module back up using a 5V USB/serial board. If anyone is interested I can post a pic. "This Way Up" posted in #184 that the Orange wire on the "OP-GPS" is the "signal" out FROM the GPS and needs to go to the green wire of the connector to the v1 air module. I connected the TxO from a 5V USB serial board to the green wire (I chopped up an interconnect) and the yellow wire to the RxI or receive in to the USB/serial board. The S.O.B. needed a mini-USB cable and I had one on hand. I plugged it in to the computer plugged it into the USB/serial board, found the comport, set it to 9600bps and fired up the
SiK radio setup program. Told it to load settings and cripes the danged thing pulled off what was setup in the "errant" v1 air module. I input the settings for the v1 ground station, saved it and all is well now.



Got 'em both back up with a solid green LED on both. Awaiting a new GPS chipset to come in and try again. I be happy here.

Now, only problem is to make sure the 500mW rig ACTUALLY puts out 500mW. Kurt

Update here on my investigations. Got my NEO-M8N GPS module via airmail from Hong Kong today.

Took me a couple of hours to figure out the wiring scheme on it. They had conflicting wire color codes on the plug, and two different color schemes indicated on the web page that sold it. I finally took the GPS plug apart with a dissecting needle, and rearranged wire colors so they would jibe with standards. (i.e. red for +5V, black for ground, yellow for signal out, and in this case green for signal in. The voltage required indicated 3.3 to 5.0 at the GPS +V, and my FTDI cable measured right at 5V. Again verified signal out of GPS using the O-scope. I was in full hacker mode at this point I guess.

I found that running the computer port at 57,600 Baud seemed to enable better U-center performance, but the GPS was factory set at 9600 Baud by using the "autobaud" feature in that program. U-Center hooked up immediately and got satellites very fast. I got full constellations of GPS, GLONASS, and the WAAS augmentation satellites. A step up from the GPS chip I originally got from AliExpress. Apparently it is ready for the European and Chinese systems as well.

In addition, I could poll the GPS settings easily, and before doing anything else I created a base configuration file (GNSS -> File). These things were not possible with the original module ordered. If I butcher a new configuration file, I can return to the factory file.

Now, I am deep in the mire of configuration file construction. This will take a while, as in days or even weeks to get up to speed on. Configuration files must be edited by hand in a text editor, with specific protocols. After several hexadecimal precedent characters that specify the command, then simply putting in a HAM call sign will require careful translation of characters to ASCII characters defined by hex bytes. (i.e. a capital "K" would be 04B in hex ASCII). In addition, the command lines have to be appended with checksum bytes, also in hex. I found a checksum calculator online that will take a little bit of the workload off.

So it is not so simple, but I am still determined. Screen shot below is the new M8N chip indoors. 16 locked satellites!! I have yet to take the thing outside, because the inland rain and wind from the hurricane are just now hitting here in Tennessee. Just as well, as I will be indoors the next few days it seems. Chip says 32 satellite channels are open, so I predict the accuracy outdoors will be quite an improvement.

"This Way Up" posted in #184 that the Orange wire on the "OP-GPS" is the "signal" out FROM the GPS and needs to go to the green wire of the connector to the v1 air module.

Click to expand...

That's why I posted the pic. Good to know it is getting used .

I'll see if I can get some work done on this next weekend.

OverTheTop said:

That's why I posted the pic. Good to know it is getting used .

I'll see if I can get some work done on this next weekend.

Click to expand...

Yes, that was the kicker there. Knowing the signal out of the GPS made all the difference in the world. That allowed me to connect up the USB/serial card to the air module and read off the settings directly. I did remember that I had previously programmed it to 9600 bits per second.
The lesson here is to remember if one reprograms the ground station without reprogramming the air module, the units can lose their connection to one another. The only way to recover the air module is to connect a USB serial cable or card.
Gauging the announcements here on the board, it appears there is going to be a plethora of new GPS trackers out there for folks to use. I believe that is a result to the price drop in the hardware.
It remains to be seen if the 500mw 3DR will offer better recovery and reception of the position sentences. It certainly is economical enough to experiment with anyways!
Sport Flyers who don't want to mess with this stuff, can be comfortable with purchasing one of the commercial sets out there. I believe one will start seeing "niche" units for different purposes. Kurt

ksaves2 said:

Ok,

Found this page that has an advanced discussion of the 3DR features: https://ardupilot.org/copter/docs/c...configuration-and-technical-information.html#

I scrolled down to the bottom and found the FTDI to USB cable to program the radios if the settings are lost. If one ends up like me, losing the settings on the "air module" of a v1 radio then
this is the page you need to go to. Also a large amount of programming information is there that might allow one to maximize range. That's what should be strived for. Kurt

Click to expand...

Aside from the link above that tells one how to restore a v1 module to stock, here is a picture of the FTDI board that did the job: (clicky for larger pic)



It's an old 5V FTDI board with a Mini USB not a Micro USB socket. From the top is ground next is VCC + (always the no brainer connections) The green wire goes to the TXO or I believe "transmit out" and the
yellow with the "green" end goes to the RXI or "receive in".

In reality I never know what Tx or Rx means but the bottom line is if you connect them crossed no harm is done. It won't work but you don't wreck anything like you do when you get the polarity wrong! Just switch the Tx/Rx wires and
try again.

Those wires are soldered on those snap off pins like this: https://www.allelectronics.com/item/shs-40/1-x-40-header-0.1-spacing/1.html

I soldered a socket like this: https://www.allelectronics.com/item/hdr-06/6-pin-stackale-header-0.1/1.html on the FTDI board. The wires are "plugable".

I remembered I had the v1 air module set for 9600bps and used the Mission Planner program to simply load settings and they came right up. I copied them down.
I then disconnected and attached my v1 local/receive station to the USB port on the computer and hit "load settings" on it. I copied the settings from the v1 unit
(because I still wanted to use them) into the local/ground/receive station and saved them.

I then disconnected the v1 local/receive station and closed the Mission Planner Program. I used my battery harness for the v1 air module to supply power to it and saw the flashing green LED.
I plugged the v1 receive station into the USB socket on the computer and WHAM! solid lock. MP and the 3DR programmer pulled up both units perfectly.

Bottom line is if you have more than one 3DR set and you totally, absolutely forget the settings on the air module and forget to save the settings to the "remote" while in the program, the above is the only way to recover the air module
so it can be reprogrammed (or you reprogram the ground unit like I did to match the air module)

You'll know what I mean the first time you see that you can't get the solid green LED's on the two units. Now to wait for replacement GPS.

Oh, I forgot to add if you own any EggTimers, TRS's Eggfinders etc, one could modify one of those USB/serial cables and even though I believe they provide 3.3V, it might work. I certainly would give it a go. I had the 5V board lying around.

https://www.aliexpress.com/item/Fre...t8xB89PDxemwiZatTkDCEkRknmpDVQh8aAsdWEALw_wcB

A possible GPS to use

Still awaiting a suitable GPS replacement. Once it comes will bench test and see if I can get GPS Rocket Locator to come up. (Easiest program for most folks to use. That's what I'm shooting for something easy and stable that
anyone can use to live track.) Kurt

I have got my telemetry working, now I need to connect a bluetooth module so I can set up GPS Rocket Locator. Once that is done I'll post my learnings on getting this stuff going.

The one big thing I think I found out was to get the remote and local modules paired and configured before connecting the GPS to the remote module. I suspect the flight controllers that they normally interface through do this automatically. Making the GPS pluggable would be a simple solution to this.

Good idea. I think I whacked the GPS when I tried to program through the B/T module. I've had more luck with the HC-05 although I didn't try very hard with the HC-06. I cobbled up a wiring harness using this regulator: https://www.ebay.com/itm/DC-5V-Out-...148218&hash=item212d981fad:g:jzAAAOSwDRxZr51S
for programming use only. I use a 2S pack and that regulator isn't efficient enough to power the whole shebang.

I have a 5V Pololu regulator like this: https://www.ebay.com/itm/Pololu-5V-...604574&hash=item3d419b87c2:g:2r8AAOSwacdZbWdl
to power the radio and the GPS.

Although it looks like this one might be usable: https://www.ebay.com/itm/DC-DC-3-3V...497295?hash=item1a2fe21c8f:g:hIgAAOSwXfBZh9Cc
Problem is how stable is it one the Pot is set. Kurt

CORZERO said:

Which means this image is incorrect?

View attachment 326808

Click to expand...

I confess I'm oddly passionate about this, and this image triggered me to get on my soapbox for new engineers.

That diagram is definitely incorrect. It would also be incorrect if the Rx and Tx are swapped. Why? Because in order for the wire to do its job it has to be connected to an Rx on one end and a Tx on the other. Therefore a label of Rx or Tx on a wire connecting the two can never provide any useful information. It's completely ambiguous each and every time, without exception. But it's astonishing how often people still do this, including professional aerospace engineers. (Source: I created the database that defined all the wiring connections on the Orion spacecraft) This oddly common mistake has probably caused billions of dollars of engineering mistakes and re-work over the years. If a wire is connecting a transmitter on gadget A and a receiver on gadget B, call the wire A2B, A_to_B or whatever other name clearly indicates the direction. "ATx" or "BRx" or similar isn't as good because can still easily be misinterpreted, but at least there is a better than a 50% chance of it being interpreted correctly. But labeling a wire as Tx alone is just dead wrong, every time. There's never a good reason for it. New engineers: Don't do this!

Well, the only thing I can say Adrian is I agree but the only way to be certain is bench test and make sure one can "cross" Rx and Tx channels for testing. If one way doesn't work, it will usually work if one switches the wires.
+ and - is always the no brainer. I can't recall dorking anything if I got Rx/Tx crossed. It's a PITA if solder connections have been made though! +/- easy though I've wrecked stuff when it was expecting 3.3V and I connected up 5V! Kurt

Adrian for president!

Pile on: when you write software, don't use variable names like x or out1. Instead use: kalmanFilterInputX or kalmanFilterOutputX...and of course don't forget: magicFudgeFactorIDontKnowWhyThisIsRequired.

ksaves2 said:

Well, the only thing I can say Adrian is I agree but the only way to be certain is bench test and make sure one can "cross" Rx and Tx channels for testing. If one way doesn't work, it will usually work if one switches the wires.
+ and - is always the no brainer. I can't recall dorking anything if I got Rx/Tx crossed. It's a PITA if solder connections have been made though! +/- easy though I've wrecked stuff when it was expecting 3.3V and I connected up 5V! Kurt

Click to expand...

That's great on the bench, and I agree each end is generally designed not to be damaged if they're crossed. But there are times in a production or aerospace environment when making that swap that would take seconds on the bench costs 10s of thousands of dollars, if not millions of dollars, to fix. A bit off-topic here though, I admit.

I confess I'm oddly passionate about this, and this image triggered me to get on my soapbox for new engineers.

That diagram is definitely incorrect. It would also be incorrect if the Rx and Tx are swapped. Why? Because in order for the wire to do its job it has to be connected to an Rx on one end and a Tx on the other. Therefore a label of Rx or Tx on a wire connecting the two can never provide any useful information. It's completely ambiguous each and every time, without exception. But it's astonishing how often people still do this, including professional aerospace engineers. (Source: I created the database that defined all the wiring connections on the Orion spacecraft) This oddly common mistake has probably caused billions of dollars of engineering mistakes and re-work over the years. If a wire is connecting a transmitter on gadget A and a receiver on gadget B, call the wire A2B, A_to_B or whatever other name clearly indicates the direction. "ATx" or "BRx" or similar isn't as good because can still easily be misinterpreted, but at least there is a better than a 50% chance of it being interpreted correctly. But labeling a wire as Tx alone is just dead wrong, every time. There's never a good reason for it. New engineers: Don't do this!

Click to expand...

Definitely. Anyone remember RS232 "standard" Was that Tx on the Data Terminal Equipment, or Data Communication Equipment? Definitions swapped depending on which. Add things into the middle of the link and it gets even more ambiguous.

My experience with this telemetry link proves things have not improved in the past 40 years in this regard, although the equipment is MUCH smaller :wink:


The good news is I have Rocket Locator running as of last night. I'll do some testing and document what was done to get it to that stage in the next few days.

OverTheTop said:

Definitely. Anyone remember RS232 "standard" Was that Tx on the Data Terminal Equipment, or Data Communication Equipment? Definitions swapped depending on which. Add things into the middle of the link and it gets even more ambiguous.

My experience with this telemetry link proves things have not improved in the past 40 years in this regard, although the equipment is MUCH smaller :wink:


The good news is I have Rocket Locator running as of last night. I'll do some testing and document what was done to get it to that stage in the next few days.

Click to expand...

Great, you got the B/T connection sending the strings to "GPS Rocket Locator" on an Android device? Now the real fun begins seeing if this is just as good or better than some of the other system out there.
When I mean "better" I mean more recovery of live positions via Rf for map tracking. Shoot, I've never lost a rocket flying a 100mW, 900Mhz tracker as I can get enough positions to find the completely out of
sight flights. I'd like to see a "prettier" live map but I guess you can call me weird.

I do have some insight with APRSISCE/32 program when I run two instances to live track. I'm thinking that perhaps there might be a latency with running two instances of the application.
One to track the NMEA rocket the other to track the local NMEA position and "send it to" the first instance that is tracking the rocket. Well the 1st instance has to listen to an APRSIS port to plot the local position and it might be
that perhaps this blocks some of the incoming positions from the rocket.

So simply, I just run the 1st instance for the rocket and shut off the network port monitoring at least while the rocket is in flight. Heck I don't need to know where I'm standing while with rocket is in flight. I need to have the electronics plot
the flight on the map. Once the rocket is down, I can continue to monitor the rocket stream and then fire up the second instance for my local position to start plotting my position on the map. Simple. If I see more rocket positions plotted, I can
assume it was the vagaries of running two programs at once. If not, it's the issues with the rocket dynamics and the tracker itself (ie. power output, antenna etc.)

Even if one could get a reliable position once every 2 or 3 seconds that would still out perform APRS tracking at once every 5 seconds. Even with long high descents with APRS I've sometimes witnessed no positions for 10 to 15 seconds with the lower powered
Beeline GPS tracker. More power and better receive antennas can help immensely with decoding of the positions. Kurt

Careful with the high-power transmitters interfering with the GPS receiver. I have seen GPS units unable to achieve lock with the telemetry Tx chirping. Shut down the Tx, GPS locks, then re-enable the Tx and the GPS maintains lock (albeit under duress). Something to consider.

Shows that there should be good electrical separation between the two units. I suspect ferrite beads/toroids and feedthrough capacitors from one side of a ground plane to the other (one unit on each side) would be the go.

Interestingly the 500mW version interferes with our digital TV if the power level is cranked up and at about a 20' range.

OverTheTop said:

Careful with the high-power transmitters interfering with the GPS receiver. I have seen GPS units unable to achieve lock with the telemetry Tx chirping. Shut down the Tx, GPS locks, then re-enable the Tx and the GPS maintains lock (albeit under duress). Something to consider.

Shows that there should be good electrical separation between the two units. I suspect ferrite beads/toroids and feedthrough capacitors from one side of a ground plane to the other (one unit on each side) would be the go.

Interestingly the 500mW version interferes with our digital TV if the power level is cranked up and at about a 20' range.

Click to expand...

That's weird. I've run the AP510 without issue. I just plugged in my "defunct" I believe Neo 7 Chinese GPS into that serial board in post #224. Weird thing is it's working as far as receive is concerned with U-center. 9600bps and nominal NMEA strings. I suspect it's not programmable since it's a clone. Will try to cobble it into a unit and see if it works.
Rf interference between the GPS and the 433Mhz transmitter would be a negative game changer. Kurt

Rf interference between the GPS and the 433Mhz transmitter would be a negative game changer. Kurt

Click to expand...

Something to be aware of and design the layout around. It is basically splattering the GPS to some degree, affecting the signal/noise ratio, by overloading the front-end on the GPS.

OverTheTop said:

Something to be aware of and design the layout around. It is basically splattering the GPS to some degree, affecting the signal/noise ratio, by overloading the front-end on the GPS.

Click to expand...

This might be a bust here. Plugged in this GPS: https://www.aliexpress.com/item/HAK...32799709822.html?spm=a2g0s.8937460.0.0.lWTIuU after I confirmed it worked with the board in msg #224. I got a very good lock indoors through the serial link direct to the computer. Connected the GPS through a 5V voltage regulator in parallel to the 3DR radio and got the red power LED and no blue no matter how long I waited. I then disconnected the plug from the radio and since the power is connected in parallel, the GPS stayed powered. Once the blue LED started flashing, signifying a lock, I plugged it back into the radio. The "receive" end was connected up to the computer already. The radio came up and the blue LED kept flashing. I could get the SIK Radio Config program to come up and the NMEA strings started coming across.

Problem there was the position was dancing all over the screen on a live mapping program. Increased the "air" communication rate and shut off ECC and OP resend and that seemed to help but still,
this was more unstable than the commercial NMEA trackers or the Beeline APRS trackers. Unless a stable setting can be found in the configuration program or a different GPS gives a better result, I'm afraid this will be a dead end. This is with the 500mW 433Mhz radio. Perhaps there is a way to shut off the bi-directional link and have the tracker "transmit"
and the "receiver" receive?

To recap, I had to let the GPS get a lock first before plugging in the GPS. Not a convenient way to start the tracker. Any thoughts from others? Again, I do not recommend this for the neophyte for now.
Kurt

Correct design for internal EMC should get you over the line. It could be an internal electromagentic compatibility problem. If the Tx messes with the clock on the GPS the accuracy could really take a hit. Clock jitter is crucial in GPS receivers.

I got mine going roughly on the bench in the "scatter assembly" mode, just to prove it would work. Now I will do a proper sled with some EMC considerations designed in and see if the GPS is ok with that.

One thing to note about the dancing location. Did the unit have a limited view of the sky? Unless there is a good scatter of satellites around the sky the error bars on the pseudoranges create quite a wild dilution of precision. A good view of the sky allows the nice mathematics to reduce the error due to constellation geometry.

Getting somewhere. Unfortunately I have to let the GPS get a lock before I plug it into the Air module. Mark my words, only program when you have the air module attached to a battery harness only.
I tried programming with the GPS attached and the module got whacked and the lock was lost between units. I had to pull out FTDI board in message #224 above to bring it back up.
It is O.K. to read the modules with the GPS attached and go into terminal mode or monitor signal strength or what have you. Don't change the settings with the GPS attached. I did it with careless abandon
and got away with it but have whacked it a few times since.
Here are the settings I find work better:


I cut the Window down to 60ms, shut off error correction and op resend.

Here's a shot of a position on APRSISCE32 in the driveway:



It shows the spread of the "jitter". Not too bad.

Only problem is having to wait for the GPS to get a lock before plugging into the radio. Will have to see if there is a sweet spot of the settings.

I do have some screen saves on the Nexus 7 2013 using GPS Rocket Locator and my Bluetooth enabled receiver. I got them to pair and display positions. Have some local screen saves of it. I need to do a drive around with the screen recorder on and see what transpires. I'll have to do that in another post. Still some concern with local interference between the 500mW transmitter and the GPS. I have another GPS coming of a different Ublox chipset. I wish I would have bought a couple more Neo6 evaluations units with the amplified Sarantel antenna:
https://www.csgshop.com/category.php?id_category=16&p=6 unfortunately out of production. This place has brand chipsets but of course they cost. Well I gotta go outside and retrieve
the air module. Kurt