Tracker4 GPS not working


New member
When I received my Tracker4, it would not give a GPS fix.

I opened the box, and saw the GPS antenna cable was not connected to the GPS module. I put it back in place and secured it with a strap. Then the LED on the front panel blinked green as documented and the position was available.

Next I had troubles connecting to my WiFi network, and could not connect until I changed my router settings to broadcast the WiFi SSID.

Then I ran the "update" command, and loaded the latest version of the firmware.

Since then, the LED's do not behave as documented any longer (fast alternating red/green), and I cannot get a GPS position any longer.

How can this be addressed ?
I agree that other than for casual monitoring - the status LEDs are not very useful.

I mentioned in my post wanting an option for each service to run in a verbose mode with a 'log view' tab to review logging would be useful. There are no man pages, so hard to tell whether you can enable/run services with a -v option or not.

I found that having the console/serial session established, USB power present and DC power coming from the transformer caused the Tracker4 to misbehave, so I would recommend not having USB connected or power signals from the data/power/radio cable while powered via the transformer. I believe the recommendation is to protect the power lead so no spurious ground signals would be received.

Re: WiFi stability. This is tricky even for major manufacturers. In a 'quiet' area you will probably find fairly reliable connectivity. Once you get overlapping signals then you'll find that the less expensive gear will disconnect. It appears that once disconnected, the Tracker4 does not make an attempt to reconnect/reset. I had to use console/serial to re-enable the WiFi. I'd like to run a cron script to periodically check and re-enable if WiFi is down. I would think the same would be true for i-gate. It appears that once established, i-gate prefers the server it was talking to despite the status on the other side. It would be nice to test that connection periodically, then reset and re-establish. Cisco for example would use time servers simply as a method of verifying internet connectivity - would be nice if this sort of thing was used. I don't think the Tracker4 is running ntpd (network time protocol).
And ha ha on me - was testing for a YouTube follow-up and just like you, the update to 162 hosed me. The unit no longer activates GPS and does not want to broadcast its WiFi network to connect to.

Warning to others. Don't update until this is addressed.
So far, the device is totally useless to me. Quite disappointing.

When I read the Tracker4 ships since August 2018, I am surprised these issues are still not fixed and there is so little activity in this forum.

I am willing to contribute to test firmware releases, and fully appreciate the technical challenges involved, but this does not look "right".
Last edited:
Hey Richard - am interested to know what problems you are running into.

I saw your earlier post. I added some troubleshooting steps if you can go through those and tell us what is going on. That will help others.
Last edited:
What a pain in the *ss this whole Tracker4 experience has been. Build 162 definitely appears to kill GPS. This is my second T4, the first one is still dead, in a basket in the closet.

Finding this group again was hard as well - there doesn't seem to be a link to it from the argentdata website, but discovered via email history that I'd set up a user name a long time ago and was able to reconstruct the route %^)

OK, enough venting.

Conrad, thanks for the link to 145, was figuring out how to get it into the Tracker4, then looked at the D: drive (Windows 10 box, connected to Tracker via USB and PuTTY) and saw t4-161.bin, so thought I'd give that a try.

Lo and behold, that worked, at least got the GPS running again.

So now maybe connect a radio (also in the basket in the closet, with the ArgentData cable for the radio) and see if this one will receive or transmit audio. That's the problem with the other one - PTT works but no audio.

Richard, attached is T4-161.bin, assuming it will attach. This was on the T4 drive, as shipped.


That's excellent, thanks! I was able to perform a downgrade from 162 to 161 using the firmware version you attached here.

I'm assuming that with the Tracker in debug mode, you might should be able to sort out the transmit volume issue. Assuming that it is a unique configuration issue. Should probably create a new thread for that, but would be interested in learning about the radio you are using and what the symptom looks like.

BTW if it makes you feel better, I bailed and decided to try out a Raspberry Pi 4 running Xastir => TinyTrak 4 and have yet to get the configuration up and running. I know the failure point is the Xastir configuration but figuring out why that is has involved many hours and I'm sure many more to come.

Alright, now that I have this Tracker 4 blipping again, need to test it out.
Good evening Conrad -

Glad to hear another human out there! %^)

And that 161 appeared to work for you as well.

You mention the RPi, I haven't tried Xastir yet. It was my frustration with the T4 (and my T3 which up and died on me back in October) that made me look for alternatives. I found direwolf, and found it to be *complicated* but once set up and married to a handy Baofeng (which sux as a receiver) that direwolf on the RPi3 works well, and is pretty reliable. I built a nice little PTT interface board (which I doubt I'll ever do again, but it was a solid lesson %^) and the Baofeng/direwolf combo chugs along. I never got telemetry working, it's supposed to support it, but the sample files and my sore lack of python skills have allowed me to have an excuse in not getting that working (yet).

I found the laundry basket with the radios, original T4, and some cables. Connected up a VX-150 using a DIY cable from a half-decade ago to the T4, and set the Yaesu FT-2D on the patio table and the T4/VX-150 combo does receive the beacon packet from the Yaesu. Wow, so much better than before (when it didn't do squat).

Transmit appears to be another thing - dtmfsend 1234567890 doesn't work, neither does ptt on, so something else I'm sure that's not configured correctly.

Cheers and 73 - Jon N7UV
Whoo-hoo! IT'S ALIVE!!!

Changed ht_ptt to true, that fixed the transmit. XMT'ed audio sounds a little bright, but the Yaesu decodes it, so that's something at least.

Here's an interesting thing: the R/G ACT LED is blinking green/off twice a second with GPS data received. The beacon packet when it transmits is maybe 0.5 sec or longer, but the ACT LED only shows a hint of difference from the regular green flash. Like the red LED came on for 50 ms or so and the green got a little yellow-ish. I'd think the RED would be on as long as the transmitter was keyed, but no.

Ok. I'm done with this for tonight. More playing around manana.

Cheers and 73 - Jon N7UV
Glad to hear Jon - yea I'm not sure how well you can decode what the indicators mean just by trial and error. Seems that also those status lights changed from firmware to firmware. That's why I just went with the debug logging.

I did get this TT4 to beacon but the APRS I-gate density in my area is low and my HT isn't reaching anything. For me the pain part was the gps and port conflicts. Still not sure that the configuration will reliably come back up after restarts but at least I've gotten somewhere.

Also - glad to know I'm not the only one with a basket full of misc. crap. Ha, well, I say that my wife moved my crap into small plastic bins so it looks more organized. I am using this time at home though to try to sort everything out and get rid of what I don't need.
Hi Conrad -

Still on build 161. More news on the LED front: The ACT light seems to perform a number of functions. The TX/RX light, on the other hand, seems to perform NO functions. At least none that I've seen so far.

For the commands BEACON <text>, DTMFSEND <digits>, and TONE <freq>, at least, they all cause the transmitter to key and transmit as required. At no time does the RX/TX LED activate. However, the ACT LED does come on for anywhere between an imperceptible to a fairly short period of time (a few hundred ms) independent of the size of the payload. For instance, loading up the command BEACON QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ (you get the idea) indeeds sends a huge number of Qs in a beacon message, but the ACT LED may not show it at all just as often as it just shows a hint of yellow as much as it shows a solid red for a few hundred ms. It's like there's some process queue for the LED, and if a competing process comes along at the wrong moment, the command to illuminate the ACT LED doesn't get through. The GPS sentence reception seems to be the process that "owns" the LED.

IDENT does appear to "kinda" work on 161. It did (i remember, I think, I'm afraid to go there again right now) on 162, and in fact flashed both LEDS in unison showing a sickly yellowish-orange (both red and green chips in each LED ON at the same time) 8 times over a period of perhaps 2 seconds. Now, depending on where in some loop cycle the command is issued from the keyboard, the LEDs may come on for a brief (100-300 ms?) period of time or not at all, or somewhere in between, just like for the commands above.

So the IDENT command shows that the TX/RX LED is connected electrically, but not being used properly by s/w.

A message received by the T4 may or may not cause the ACT LED to do much of anything different, I suspect that it might lengthen the green time if timed just right.

It would appear to me that the internal software processes that expect to trigger the TX/RX LED are misdirected to the ACT LED. That could be a simple code fix, or not...

Anyway, gotta run for a little while.

Cheers and 73 - Jon N7UV

Scott Miller

Staff member
Hey all, sorry to be absent so long. Things had gotten really hectic here before we went into lockdown. I can't have any employees in, but I've got a comfy RV already parked at the shop so I'm just living here for the duration and spending all of my waking hours trying to keep up. It's a losing battle, but I should be able to cover the most critical stuff until I can have help again.

Anyway, I've got a new update out that's detailed more in the "hang in there" thread. This should fix the GPS parsing issues. There was also a DMA bug causing dropped NMEA data, which revealed another bug that was getting the parser stuck in a mode where it was just parsing junk repeatedly, which would likely account for some of the weird LED behavior.

You can use the 'update' command to get the update as well. See my warning in that other thread about some cosmetic issues with the front end if you do that.

Try the firmware update, and let me know what happens.