Date   
LightAPRS Tracker

Mustafa Tan
 

Hi,

Three years ago I was googling about high altitude balloons and I ended up with pico (floater) balloon projects. I was really impressed with some amateur radio operators efforts to circumnavigate around the world with party balloons and track them.

Six months later I got my amateur radio license and started flights with heavy APRS trackers. Since payload is very heavy, balloons maximum altitude never exceeded 9.000 meters and modules I used was not frequency agile.

So we (TA2MUN and TA9OHC) decided to develop a lightweight, extendable, affordable and open source APRS tracker. Since our tracker is very light and frequency agile, it's very convenient for pico (floater) balloon and HAB (High Altitude Balloon) projects. LightAPRS Tracker has been developed for nearly two years now and has been proven on many flights.

You can check out our tracker using following links:

Github page : https://github.com/lightaprs/LightAPRS-1.0
Shop : http://www.qrp-labs.com/lightaprs.html

Please do not hesitate to share if you have questions or comments about our tracker 

TA2MUN

GPS Rollover

Harry M
 

GPSL Registration

Mike, n0mpm
 

GPSL 2019 registration is now open and available.    Please go to “superlaunch.org” for details on hotels, registration fees, and group dinners.  Hope to see you all in Pella, IA on June 13, 14 and 15 !!!!

Mike, n0mpm

Re: GPSL Registration

Bruce Coates
 

Hi Mike

Leigh (VE5LEE) and I (VE5BNC) had hoped to attend but, in a fit of wander lust, ended up booking a trip around Europe in June.  GPSL is a ton of fun but Amsterdam, Prague, Vienna, Venice and Paris won out this time. 

Have fun everyone!

Bruce - SABRE

------ Original message------
From: Mike, n0mpm
Date: Thu, Mar 21, 2019 4:26 PM
Cc:
Subject:[GPSL] GPSL Registration

GPSL 2019 registration is now open and available.    Please go to “superlaunch.org” for details on hotels, registration fees, and group dinners.  Hope to see you all in Pella, IA on June 13, 14 and 15 !!!!

Mike, n0mpm

MAX-M8Q GPS lock problem

Zack Clobes W0ZC
 

I'm looking for some ideas on troubleshooting some lock problems on a new board/capsule/camera design.  The board has worked well during testing up until I started integration testing with the actual capsule with the cameras under it.  

The capsule is about 6cm thick and is mostly two layers of foam.  There are two cameras sandwiched in the middle and there is an aluminum bar holding them in place.  The GPS antenna is as far away from that as I can get.  Lid open or lid closed doesn't seem to make any difference.

During testing I noticed that this board would take a lot longer to get a lock than it's identical sister.  Initially I thought it was a bad GPS or antenna, and eventually replaced both.  Then I noticed if I unplug an external (optics) sensor, the GPS would lock up almost immediately.

So I nixed the sensor at the 11th hour and went flying.  The GPS never locked on a single time during the whole flight.  There's about 2m of separation to the next capsule.


This morning I plugged everything back in just like it flew, and it immediately got a lock.  The only thing I noticed was that after powering up the cameras, the altitude was reading about 100 meters high.  But I still had 5-9 sats.


I'm running low on ideas on what to try to isolate this problem. 


Zack

Re: MAX-M8Q GPS lock problem

Michael
 

Looks like you have an EMI issue, try wrapping the cameras with aluminum foil with just a small hole for the lens as small as you can get it without interfering with the view. Most likely your cameras are using a frequency that has a harmonic on the GPS frequency and with a GPS having say 165db of sensitivity, you pretty much can not get far enough away on a flight string to realize some impact, but more shielding and space will likely help. 

--Michael Willett
K5NOT

On Mar 23, 2019, at 11:08 AM, Zack Clobes W0ZC <zclobes@...> wrote:

I'm looking for some ideas on troubleshooting some lock problems on a new board/capsule/camera design.  The board has worked well during testing up until I started integration testing with the actual capsule with the cameras under it.  

The capsule is about 6cm thick and is mostly two layers of foam.  There are two cameras sandwiched in the middle and there is an aluminum bar holding them in place.  The GPS antenna is as far away from that as I can get.  Lid open or lid closed doesn't seem to make any difference.

During testing I noticed that this board would take a lot longer to get a lock than it's identical sister.  Initially I thought it was a bad GPS or antenna, and eventually replaced both.  Then I noticed if I unplug an external (optics) sensor, the GPS would lock up almost immediately.

So I nixed the sensor at the 11th hour and went flying.  The GPS never locked on a single time during the whole flight.  There's about 2m of separation to the next capsule.


This morning I plugged everything back in just like it flew, and it immediately got a lock.  The only thing I noticed was that after powering up the cameras, the altitude was reading about 100 meters high.  But I still had 5-9 sats.


I'm running low on ideas on what to try to isolate this problem. 


Zack
<IMG_20190319_163333.jpg>
<IMG_20190319_163351.jpg>

Re: MAX-M8Q GPS lock problem

Jeff Ducklow
 

I second Micheal's advice. I once had an EMI issue with a GoPro camera not allowing a GPS lock. My solution involved the cover from an Altoids tin. Once I had enough metal between the GPS unit the GoPro I was back in business.

Jeff Ducklow
N0NQN

On March 23, 2019 at 11:58 AM Michael <mw@...> wrote:

Looks like you have an EMI issue, try wrapping the cameras with aluminum foil with just a small hole for the lens as small as you can get it without interfering with the view. Most likely your cameras are using a frequency that has a harmonic on the GPS frequency and with a GPS having say 165db of sensitivity, you pretty much can not get far enough away on a flight string to realize some impact, but more shielding and space will likely help. 

--Michael Willett
K5NOT

On Mar 23, 2019, at 11:08 AM, Zack Clobes W0ZC < zclobes@...> wrote:

I'm looking for some ideas on troubleshooting some lock problems on a new board/capsule/camera design.  The board has worked well during testing up until I started integration testing with the actual capsule with the cameras under it.  

The capsule is about 6cm thick and is mostly two layers of foam.  There are two cameras sandwiched in the middle and there is an aluminum bar holding them in place.  The GPS antenna is as far away from that as I can get.  Lid open or lid closed doesn't seem to make any difference.

During testing I noticed that this board would take a lot longer to get a lock than it's identical sister.  Initially I thought it was a bad GPS or antenna, and eventually replaced both.  Then I noticed if I unplug an external (optics) sensor, the GPS would lock up almost immediately.

So I nixed the sensor at the 11th hour and went flying.  The GPS never locked on a single time during the whole flight.  There's about 2m of separation to the next capsule.


This morning I plugged everything back in just like it flew, and it immediately got a lock.  The only thing I noticed was that after powering up the cameras, the altitude was reading about 100 meters high.  But I still had 5-9 sats.


I'm running low on ideas on what to try to isolate this problem. 


Zack
<IMG_20190319_163333.jpg>
<IMG_20190319_163351.jpg>

 

 

Re: MAX-M8Q GPS lock problem

Zack Clobes W0ZC
 

Most of my testing that I did was with the cameras powered down.  

That's what is throwing me on this one - sensor seems to cause problems so I yank that, then it seems like the cameras are doing it, but I remind myself that I didn't have them turned in through most of the testing.  

I do have E/H probes on their way for the spectrum analyzer.  


I need to recharge the battery then I'll try the foil to see if it changes anything...

Zack


On Sat, Mar 23, 2019, 12:31 PM Jeff Ducklow <jeffducklow@...> wrote:
I second Micheal's advice. I once had an EMI issue with a GoPro camera not allowing a GPS lock. My solution involved the cover from an Altoids tin. Once I had enough metal between the GPS unit the GoPro I was back in business.

Jeff Ducklow
N0NQN

On March 23, 2019 at 11:58 AM Michael <mw@...> wrote:

Looks like you have an EMI issue, try wrapping the cameras with aluminum foil with just a small hole for the lens as small as you can get it without interfering with the view. Most likely your cameras are using a frequency that has a harmonic on the GPS frequency and with a GPS having say 165db of sensitivity, you pretty much can not get far enough away on a flight string to realize some impact, but more shielding and space will likely help. 

--Michael Willett
K5NOT

On Mar 23, 2019, at 11:08 AM, Zack Clobes W0ZC < zclobes@...> wrote:

I'm looking for some ideas on troubleshooting some lock problems on a new board/capsule/camera design.  The board has worked well during testing up until I started integration testing with the actual capsule with the cameras under it.  

The capsule is about 6cm thick and is mostly two layers of foam.  There are two cameras sandwiched in the middle and there is an aluminum bar holding them in place.  The GPS antenna is as far away from that as I can get.  Lid open or lid closed doesn't seem to make any difference.

During testing I noticed that this board would take a lot longer to get a lock than it's identical sister.  Initially I thought it was a bad GPS or antenna, and eventually replaced both.  Then I noticed if I unplug an external (optics) sensor, the GPS would lock up almost immediately.

So I nixed the sensor at the 11th hour and went flying.  The GPS never locked on a single time during the whole flight.  There's about 2m of separation to the next capsule.


This morning I plugged everything back in just like it flew, and it immediately got a lock.  The only thing I noticed was that after powering up the cameras, the altitude was reading about 100 meters high.  But I still had 5-9 sats.


I'm running low on ideas on what to try to isolate this problem. 


Zack
<IMG_20190319_163333.jpg>
<IMG_20190319_163351.jpg>

 

 

Re: MAX-M8Q GPS lock problem

Michael
 

Troubleshooting EMI can be fun... try doing this while at an FCC lab where the clock is ticking $$$ and you are calculating beat frequencies on almost unrelated things in a system to get a clue why/who is causing issues, and when you get the thing to pass it is not pretty but you have a clue and go back to the lab and implement changes that production can also implement and go back to the FCC lab with fingers crossed that you solved the issue. That is why they invented anti-anxiety drugs. :)

--Michael Willett

On Mar 23, 2019, at 12:36 PM, Zack Clobes W0ZC <zclobes@...> wrote:

Most of my testing that I did was with the cameras powered down.  

That's what is throwing me on this one - sensor seems to cause problems so I yank that, then it seems like the cameras are doing it, but I remind myself that I didn't have them turned in through most of the testing.  

I do have E/H probes on their way for the spectrum analyzer.  


I need to recharge the battery then I'll try the foil to see if it changes anything...

Zack

On Sat, Mar 23, 2019, 12:31 PM Jeff Ducklow <jeffducklow@...> wrote:
I second Micheal's advice. I once had an EMI issue with a GoPro camera not allowing a GPS lock. My solution involved the cover from an Altoids tin. Once I had enough metal between the GPS unit the GoPro I was back in business.

Jeff Ducklow
N0NQN

On March 23, 2019 at 11:58 AM Michael <mw@...> wrote:

Looks like you have an EMI issue, try wrapping the cameras with aluminum foil with just a small hole for the lens as small as you can get it without interfering with the view. Most likely your cameras are using a frequency that has a harmonic on the GPS frequency and with a GPS having say 165db of sensitivity, you pretty much can not get far enough away on a flight string to realize some impact, but more shielding and space will likely help. 

--Michael Willett
K5NOT

On Mar 23, 2019, at 11:08 AM, Zack Clobes W0ZC < zclobes@...> wrote:

I'm looking for some ideas on troubleshooting some lock problems on a new board/capsule/camera design.  The board has worked well during testing up until I started integration testing with the actual capsule with the cameras under it.  

The capsule is about 6cm thick and is mostly two layers of foam.  There are two cameras sandwiched in the middle and there is an aluminum bar holding them in place.  The GPS antenna is as far away from that as I can get.  Lid open or lid closed doesn't seem to make any difference.

During testing I noticed that this board would take a lot longer to get a lock than it's identical sister.  Initially I thought it was a bad GPS or antenna, and eventually replaced both.  Then I noticed if I unplug an external (optics) sensor, the GPS would lock up almost immediately.

So I nixed the sensor at the 11th hour and went flying.  The GPS never locked on a single time during the whole flight.  There's about 2m of separation to the next capsule.


This morning I plugged everything back in just like it flew, and it immediately got a lock.  The only thing I noticed was that after powering up the cameras, the altitude was reading about 100 meters high.  But I still had 5-9 sats.


I'm running low on ideas on what to try to isolate this problem. 


Zack
<IMG_20190319_163333.jpg>
<IMG_20190319_163351.jpg>

 

 

Re: MAX-M8Q GPS lock problem

Bill Brown
 

Hi Zack,

  Digital cameras are a huge source of EMI to desense GPS receivers. I always try to keep about 6 to 10 feet of isolation between GPS trackers and camera payloads. Aluminum shielding on the top or bottom of the camera payload is also a good idea.

  By identical sister do you mean the other board also uses the MAX-8Q or does it use some other version of the MAX series?  In the case of the MAX-8Q if you don't send it the command to only use the US GPS constellation, it will also use the Chinese and Russian GPS sytems and will access more satellites. That might help.

- Bill WB8ELK

I use the MAX-7Q and MAX-8Q almost exclusively now. However, for extreme EMI environments such as coexisting next to an ATV transmitter with digital cameras, then I use the Trimble Copernicus module as it is a lot more impervious to EMI effects. I still offer them every once in awhile for folks using ATV on gliders or RC aircraft as well as ATV payload on balloons.


-----Original Message-----
From: Michael <mw@...>
To: GPSL <GPSL@groups.io>
Sent: Sat, Mar 23, 2019 11:58 am
Subject: Re: [GPSL] MAX-M8Q GPS lock problem

Looks like you have an EMI issue, try wrapping the cameras with aluminum foil with just a small hole for the lens as small as you can get it without interfering with the view. Most likely your cameras are using a frequency that has a harmonic on the GPS frequency and with a GPS having say 165db of sensitivity, you pretty much can not get far enough away on a flight string to realize some impact, but more shielding and space will likely help. 

--Michael Willett
K5NOT

On Mar 23, 2019, at 11:08 AM, Zack Clobes W0ZC <zclobes@...> wrote:

I'm looking for some ideas on troubleshooting some lock problems on a new board/capsule/camera design.  The board has worked well during testing up until I started integration testing with the actual capsule with the cameras under it.  

The capsule is about 6cm thick and is mostly two layers of foam.  There are two cameras sandwiched in the middle and there is an aluminum bar holding them in place.  The GPS antenna is as far away from that as I can get.  Lid open or lid closed doesn't seem to make any difference.

During testing I noticed that this board would take a lot longer to get a lock than it's identical sister.  Initially I thought it was a bad GPS or antenna, and eventually replaced both.  Then I noticed if I unplug an external (optics) sensor, the GPS would lock up almost immediately.

So I nixed the sensor at the 11th hour and went flying.  The GPS never locked on a single time during the whole flight.  There's about 2m of separation to the next capsule.


This morning I plugged everything back in just like it flew, and it immediately got a lock.  The only thing I noticed was that after powering up the cameras, the altitude was reading about 100 meters high.  But I still had 5-9 sats.


I'm running low on ideas on what to try to isolate this problem. 


Zack
<IMG_20190319_163333.jpg>
<IMG_20190319_163351.jpg>

Re: MAX-M8Q GPS lock problem

Leo Bodnar
 

You don't need RFI interference in GPS L1 band to disable GPS.

Ublox MAX-8Q and all other MAX series modules do not have *any* antenna input preselector filtering - just an impedance match.  Their antenna input is attached to on-chip LNA followed by a mixer.  Imagine bypassing all the bandpass filters in your HAM rig and trying to listen to DX station close to a powerful nearby broadband transmitter.

For complex payloads I would suggest using either module with internal filter - like NEO - or simply placing a GPS band SAW filter between the antenna and the module.  Having only a few dB insertion loss It would not hurt the sensitivity but can help with nearby out of band EMI.  If you really need these few extra dB back take it out and bypass it with a short piece of wire.

Cheers
Leo

On 24 Mar 2019, at 02:55, Bill Brown via Groups.Io wrote:

Hi Zack,

  Digital cameras are a huge source of EMI to desense GPS receivers. I always try to keep about 6 to 10 feet of isolation between GPS trackers and camera payloads. Aluminum shielding on the top or bottom of the camera payload is also a good idea.

  By identical sister do you mean the other board also uses the MAX-8Q or does it use some other version of the MAX series?  In the case of the MAX-8Q if you don't send it the command to only use the US GPS constellation, it will also use the Chinese and Russian GPS sytems and will access more satellites. That might help.

- Bill WB8ELK

I use the MAX-7Q and MAX-8Q almost exclusively now. However, for extreme EMI environments such as coexisting next to an ATV transmitter with digital cameras, then I use the Trimble Copernicus module as it is a lot more impervious to EMI effects. I still offer them every once in awhile for folks using ATV on gliders or RC aircraft as well as ATV payload on balloons.


-----Original Message-----
From: Michael <mw@...>
To: GPSL <GPSL@groups.io>
Sent: Sat, Mar 23, 2019 11:58 am
Subject: Re: [GPSL] MAX-M8Q GPS lock problem

Looks like you have an EMI issue, try wrapping the cameras with aluminum foil with just a small hole for the lens as small as you can get it without interfering with the view. Most likely your cameras are using a frequency that has a harmonic on the GPS frequency and with a GPS having say 165db of sensitivity, you pretty much can not get far enough away on a flight string to realize some impact, but more shielding and space will likely help. 

--Michael Willett
K5NOT

On Mar 23, 2019, at 11:08 AM, Zack Clobes W0ZC <zclobes@...> wrote:

I'm looking for some ideas on troubleshooting some lock problems on a new board/capsule/camera design.  The board has worked well during testing up until I started integration testing with the actual capsule with the cameras under it.  

The capsule is about 6cm thick and is mostly two layers of foam.  There are two cameras sandwiched in the middle and there is an aluminum bar holding them in place.  The GPS antenna is as far away from that as I can get.  Lid open or lid closed doesn't seem to make any difference.

During testing I noticed that this board would take a lot longer to get a lock than it's identical sister.  Initially I thought it was a bad GPS or antenna, and eventually replaced both.  Then I noticed if I unplug an external (optics) sensor, the GPS would lock up almost immediately.

So I nixed the sensor at the 11th hour and went flying.  The GPS never locked on a single time during the whole flight.  There's about 2m of separation to the next capsule.


This morning I plugged everything back in just like it flew, and it immediately got a lock.  The only thing I noticed was that after powering up the cameras, the altitude was reading about 100 meters high.  But I still had 5-9 sats.


I'm running low on ideas on what to try to isolate this problem. 


Zack
<IMG_20190319_163333.jpg>
<IMG_20190319_163351.jpg>

TrackSoar

L. Paul Verhage KD4STH
 

I'm testing a TrackSoar APRS tracker before near space season begins in earnest. If you haven't seen one of these, it's a small board with GPS, GPS antenna, transmitter, Arduino, and two meter antenna. It runs from 2 'AA'  cells. You program it's Audrino with your callsign and it's ready to go.

Anyhow, I wonder if anyone is using one as I'm having a problem with mine. I see that it has a GPS lock (the GPS LED illuminates once per second) and that it's trying to transmit ( the PTT LED illuminates for 30 seconds on and off). However, my Kenwood D72 doesn't hear anything. My D72 does decode packets from my other trackers, including a Strato Track.

So if you have any experience with the TrackSoar, could you let me know?

Thanks

Re: TrackSoar

Mark Conner N9XTN
 

I have an older Kenwood TH-D7A that has trouble decoding packets that have a short TXD, especially when the squelch is turned on.  I don't know if the D72 has the same issues.  You can try running your D72 with open squelch and see if that helps.  If not, can the TXD for the TrackSoar be increased?

73 de Mark N9XTN


On Sat, Mar 30, 2019 at 7:38 PM L. Paul Verhage KD4STH <nearsys@...> wrote:
I'm testing a TrackSoar APRS tracker before near space season begins in earnest. If you haven't seen one of these, it's a small board with GPS, GPS antenna, transmitter, Arduino, and two meter antenna. It runs from 2 'AA'  cells. You program it's Audrino with your callsign and it's ready to go.

Anyhow, I wonder if anyone is using one as I'm having a problem with mine. I see that it has a GPS lock (the GPS LED illuminates once per second) and that it's trying to transmit ( the PTT LED illuminates for 30 seconds on and off). However, my Kenwood D72 doesn't hear anything. My D72 does decode packets from my other trackers, including a Strato Track.

So if you have any experience with the TrackSoar, could you let me know?

Thanks

Re: TrackSoar

L. Paul Verhage KD4STH
 

I'll try testing that. My D72 doesn't even break squelch, so I was thinking the TrackSoar wasn't even trying to transmit.

I had one suggestion to remove the comment statements and then look at debug statements. That means learning more about C for the Arduino. I can at least edit a sketch and upload it. Today I guess I'm going to learn more.

On Sun, Mar 31, 2019, 9:41 AM Mark Conner N9XTN <mconner1@...> wrote:
I have an older Kenwood TH-D7A that has trouble decoding packets that have a short TXD, especially when the squelch is turned on.  I don't know if the D72 has the same issues.  You can try running your D72 with open squelch and see if that helps.  If not, can the TXD for the TrackSoar be increased?

73 de Mark N9XTN


On Sat, Mar 30, 2019 at 7:38 PM L. Paul Verhage KD4STH <nearsys@...> wrote:
I'm testing a TrackSoar APRS tracker before near space season begins in earnest. If you haven't seen one of these, it's a small board with GPS, GPS antenna, transmitter, Arduino, and two meter antenna. It runs from 2 'AA'  cells. You program it's Audrino with your callsign and it's ready to go.

Anyhow, I wonder if anyone is using one as I'm having a problem with mine. I see that it has a GPS lock (the GPS LED illuminates once per second) and that it's trying to transmit ( the PTT LED illuminates for 30 seconds on and off). However, my Kenwood D72 doesn't hear anything. My D72 does decode packets from my other trackers, including a Strato Track.

So if you have any experience with the TrackSoar, could you let me know?

Thanks

Re: TrackSoar

Barry
 

If you mean the PTT LED is alternately on for 30 sec’s and then off for 30 sec’s you have definitely have a problem. And although it’s called a PTT LED it isn’t really a true PTT LED, but actually monitors the processor activity and is basically ON all the time.

 

From my web page at http://bear.sbszoo.com/construction/traker/Tracksoar/V1-1.htm -

The PTT LED, although it becomes bright around the time of each transmission, actually indicates when the processor is awake and busy processing instructions which is why it's dimly lit between transmissions when the processor is only awake very briefly to check if it's time for another transmission each time GPS data is received and then brightens when it's time to make a transmission and the processor remains awake for much longer. After adding the 4th new feature this LED also becomes bright every 10 sec's when the processor is kept awake while checking the altitude and for a burst which makes it hard to know when a transmission actually occurs so a configuration setting was added that allows the PTT LED to be used as either a processor activity indicator or as a real PTT indicator that's only on during a transmission.

 

My web page also has a link to my modified firmware that gives one the option to make the LED a true PTT indicator as well as to add a number of other useful features (at least I found them useful.)

 

I haven’t worked with the Tracksoar since I wrote that page in 2016 and can’t remember exactly how the so called PTT LED behaves under certain conditions so can’t help much more than above and what’s on my page.

 

Are you sure that you replaced the jumper, or jumpers, that you removed to program the unit after adding your callsign etc. to the config file?

 

The one thing I meant to check out after trying to locate a landed payload and never hearing any further transmissions after it landed was whether the Tracksoar would continue to transmit, or not, the last good data received from the gps if the gps lost lock and was unable to receive any further good data.

 

Barry
VE6SBS

 

From: GPSL@groups.io [mailto:GPSL@groups.io] On Behalf Of L. Paul Verhage KD4STH
Sent: Sunday, March 31, 2019 9:56 AM
To: GPSL@groups.io
Subject: Re: [GPSL] TrackSoar

 

I'll try testing that. My D72 doesn't even break squelch, so I was thinking the TrackSoar wasn't even trying to transmit.

 

I had one suggestion to remove the comment statements and then look at debug statements. That means learning more about C for the Arduino. I can at least edit a sketch and upload it. Today I guess I'm going to learn more.

 

On Sun, Mar 31, 2019, 9:41 AM Mark Conner N9XTN <mconner1@...> wrote:

I have an older Kenwood TH-D7A that has trouble decoding packets that have a short TXD, especially when the squelch is turned on.  I don't know if the D72 has the same issues.  You can try running your D72 with open squelch and see if that helps.  If not, can the TXD for the TrackSoar be increased?

 

73 de Mark N9XTN

 

 

On Sat, Mar 30, 2019 at 7:38 PM L. Paul Verhage KD4STH <nearsys@...> wrote:

I'm testing a TrackSoar APRS tracker before near space season begins in earnest. If you haven't seen one of these, it's a small board with GPS, GPS antenna, transmitter, Arduino, and two meter antenna. It runs from 2 'AA'  cells. You program it's Audrino with your callsign and it's ready to go.

 

Anyhow, I wonder if anyone is using one as I'm having a problem with mine. I see that it has a GPS lock (the GPS LED illuminates once per second) and that it's trying to transmit ( the PTT LED illuminates for 30 seconds on and off). However, my Kenwood D72 doesn't hear anything. My D72 does decode packets from my other trackers, including a Strato Track.

 

So if you have any experience with the TrackSoar, could you let me know?

 

Thanks

Re: TrackSoar

L. Paul Verhage KD4STH
 

The LED was on constantly until I turned it off the only did was not blinking for 30 seconds.


On Sun, Mar 31, 2019, 1:17 PM Barry <barry2@...> wrote:

If you mean the PTT LED is alternately on for 30 sec’s and then off for 30 sec’s you have definitely have a problem. And although it’s called a PTT LED it isn’t really a true PTT LED, but actually monitors the processor activity and is basically ON all the time.

 

From my web page at http://bear.sbszoo.com/construction/traker/Tracksoar/V1-1.htm -

The PTT LED, although it becomes bright around the time of each transmission, actually indicates when the processor is awake and busy processing instructions which is why it's dimly lit between transmissions when the processor is only awake very briefly to check if it's time for another transmission each time GPS data is received and then brightens when it's time to make a transmission and the processor remains awake for much longer. After adding the 4th new feature this LED also becomes bright every 10 sec's when the processor is kept awake while checking the altitude and for a burst which makes it hard to know when a transmission actually occurs so a configuration setting was added that allows the PTT LED to be used as either a processor activity indicator or as a real PTT indicator that's only on during a transmission.

 

My web page also has a link to my modified firmware that gives one the option to make the LED a true PTT indicator as well as to add a number of other useful features (at least I found them useful.)

 

I haven’t worked with the Tracksoar since I wrote that page in 2016 and can’t remember exactly how the so called PTT LED behaves under certain conditions so can’t help much more than above and what’s on my page.

 

Are you sure that you replaced the jumper, or jumpers, that you removed to program the unit after adding your callsign etc. to the config file?

 

The one thing I meant to check out after trying to locate a landed payload and never hearing any further transmissions after it landed was whether the Tracksoar would continue to transmit, or not, the last good data received from the gps if the gps lost lock and was unable to receive any further good data.

 

Barry
VE6SBS

 

From: GPSL@groups.io [mailto:GPSL@groups.io] On Behalf Of L. Paul Verhage KD4STH
Sent: Sunday, March 31, 2019 9:56 AM
To: GPSL@groups.io
Subject: Re: [GPSL] TrackSoar

 

I'll try testing that. My D72 doesn't even break squelch, so I was thinking the TrackSoar wasn't even trying to transmit.

 

I had one suggestion to remove the comment statements and then look at debug statements. That means learning more about C for the Arduino. I can at least edit a sketch and upload it. Today I guess I'm going to learn more.

 

On Sun, Mar 31, 2019, 9:41 AM Mark Conner N9XTN <mconner1@...> wrote:

I have an older Kenwood TH-D7A that has trouble decoding packets that have a short TXD, especially when the squelch is turned on.  I don't know if the D72 has the same issues.  You can try running your D72 with open squelch and see if that helps.  If not, can the TXD for the TrackSoar be increased?

 

73 de Mark N9XTN

 

 

On Sat, Mar 30, 2019 at 7:38 PM L. Paul Verhage KD4STH <nearsys@...> wrote:

I'm testing a TrackSoar APRS tracker before near space season begins in earnest. If you haven't seen one of these, it's a small board with GPS, GPS antenna, transmitter, Arduino, and two meter antenna. It runs from 2 'AA'  cells. You program it's Audrino with your callsign and it's ready to go.

 

Anyhow, I wonder if anyone is using one as I'm having a problem with mine. I see that it has a GPS lock (the GPS LED illuminates once per second) and that it's trying to transmit ( the PTT LED illuminates for 30 seconds on and off). However, my Kenwood D72 doesn't hear anything. My D72 does decode packets from my other trackers, including a Strato Track.

 

So if you have any experience with the TrackSoar, could you let me know?

 

Thanks

Re: TrackSoar

L. Paul Verhage KD4STH
 

Dang speech to text. The LED was on constantly for the 30 seconds I watched it. I turned off the tracker after watching it for 30 seconds.


On Sun, Mar 31, 2019, 2:53 PM L. Paul Verhage KD4STH via Groups.Io <nearsys=gmail.com@groups.io> wrote:
The LED was on constantly until I turned it off the only did was not blinking for 30 seconds.

On Sun, Mar 31, 2019, 1:17 PM Barry <barry2@...> wrote:

If you mean the PTT LED is alternately on for 30 sec’s and then off for 30 sec’s you have definitely have a problem. And although it’s called a PTT LED it isn’t really a true PTT LED, but actually monitors the processor activity and is basically ON all the time.

 

From my web page at http://bear.sbszoo.com/construction/traker/Tracksoar/V1-1.htm -

The PTT LED, although it becomes bright around the time of each transmission, actually indicates when the processor is awake and busy processing instructions which is why it's dimly lit between transmissions when the processor is only awake very briefly to check if it's time for another transmission each time GPS data is received and then brightens when it's time to make a transmission and the processor remains awake for much longer. After adding the 4th new feature this LED also becomes bright every 10 sec's when the processor is kept awake while checking the altitude and for a burst which makes it hard to know when a transmission actually occurs so a configuration setting was added that allows the PTT LED to be used as either a processor activity indicator or as a real PTT indicator that's only on during a transmission.

 

My web page also has a link to my modified firmware that gives one the option to make the LED a true PTT indicator as well as to add a number of other useful features (at least I found them useful.)

 

I haven’t worked with the Tracksoar since I wrote that page in 2016 and can’t remember exactly how the so called PTT LED behaves under certain conditions so can’t help much more than above and what’s on my page.

 

Are you sure that you replaced the jumper, or jumpers, that you removed to program the unit after adding your callsign etc. to the config file?

 

The one thing I meant to check out after trying to locate a landed payload and never hearing any further transmissions after it landed was whether the Tracksoar would continue to transmit, or not, the last good data received from the gps if the gps lost lock and was unable to receive any further good data.

 

Barry
VE6SBS

 

From: GPSL@groups.io [mailto:GPSL@groups.io] On Behalf Of L. Paul Verhage KD4STH
Sent: Sunday, March 31, 2019 9:56 AM
To: GPSL@groups.io
Subject: Re: [GPSL] TrackSoar

 

I'll try testing that. My D72 doesn't even break squelch, so I was thinking the TrackSoar wasn't even trying to transmit.

 

I had one suggestion to remove the comment statements and then look at debug statements. That means learning more about C for the Arduino. I can at least edit a sketch and upload it. Today I guess I'm going to learn more.

 

On Sun, Mar 31, 2019, 9:41 AM Mark Conner N9XTN <mconner1@...> wrote:

I have an older Kenwood TH-D7A that has trouble decoding packets that have a short TXD, especially when the squelch is turned on.  I don't know if the D72 has the same issues.  You can try running your D72 with open squelch and see if that helps.  If not, can the TXD for the TrackSoar be increased?

 

73 de Mark N9XTN

 

 

On Sat, Mar 30, 2019 at 7:38 PM L. Paul Verhage KD4STH <nearsys@...> wrote:

I'm testing a TrackSoar APRS tracker before near space season begins in earnest. If you haven't seen one of these, it's a small board with GPS, GPS antenna, transmitter, Arduino, and two meter antenna. It runs from 2 'AA'  cells. You program it's Audrino with your callsign and it's ready to go.

 

Anyhow, I wonder if anyone is using one as I'm having a problem with mine. I see that it has a GPS lock (the GPS LED illuminates once per second) and that it's trying to transmit ( the PTT LED illuminates for 30 seconds on and off). However, my Kenwood D72 doesn't hear anything. My D72 does decode packets from my other trackers, including a Strato Track.

 

So if you have any experience with the TrackSoar, could you let me know?

 

Thanks

Re: TrackSoar

Barry
 

Try leaving the tracker on longer. I’m going from memory, but I believe the GPS LED is simply tied to the 1 PPS output and it may blink regardless of whether the GPS has lock or not. The first time you power up the tracker I’m guessing the so called PTT LED may remain bright until the GPS gets a lock as the tracker processor will be constantly on (ie. not entering sleep mode to save power) until lock is achieved and if the GPS hasn’t been powered on for some time and doesn’t yet have a complete almanac saved this may take up to 10 to 15 minutes. After this the GPS will be able to get a lock much faster, like less than a minute.

 

Barry
VE6SBS

 

From: GPSL@groups.io [mailto:GPSL@groups.io] On Behalf Of L. Paul Verhage KD4STH
Sent: Sunday, March 31, 2019 3:04 PM
To: GPSL@groups.io
Subject: Re: [GPSL] TrackSoar

 

Dang speech to text. The LED was on constantly for the 30 seconds I watched it. I turned off the tracker after watching it for 30 seconds.

 

On Sun, Mar 31, 2019, 2:53 PM L. Paul Verhage KD4STH via Groups.Io <nearsys=gmail.com@groups.io> wrote:

The LED was on constantly until I turned it off the only did was not blinking for 30 seconds.

 

On Sun, Mar 31, 2019, 1:17 PM Barry <barry2@...> wrote:

If you mean the PTT LED is alternately on for 30 sec’s and then off for 30 sec’s you have definitely have a problem. And although it’s called a PTT LED it isn’t really a true PTT LED, but actually monitors the processor activity and is basically ON all the time.

 

From my web page at http://bear.sbszoo.com/construction/traker/Tracksoar/V1-1.htm -

The PTT LED, although it becomes bright around the time of each transmission, actually indicates when the processor is awake and busy processing instructions which is why it's dimly lit between transmissions when the processor is only awake very briefly to check if it's time for another transmission each time GPS data is received and then brightens when it's time to make a transmission and the processor remains awake for much longer. After adding the 4th new feature this LED also becomes bright every 10 sec's when the processor is kept awake while checking the altitude and for a burst which makes it hard to know when a transmission actually occurs so a configuration setting was added that allows the PTT LED to be used as either a processor activity indicator or as a real PTT indicator that's only on during a transmission.

 

My web page also has a link to my modified firmware that gives one the option to make the LED a true PTT indicator as well as to add a number of other useful features (at least I found them useful.)

 

I haven’t worked with the Tracksoar since I wrote that page in 2016 and can’t remember exactly how the so called PTT LED behaves under certain conditions so can’t help much more than above and what’s on my page.

 

Are you sure that you replaced the jumper, or jumpers, that you removed to program the unit after adding your callsign etc. to the config file?

 

The one thing I meant to check out after trying to locate a landed payload and never hearing any further transmissions after it landed was whether the Tracksoar would continue to transmit, or not, the last good data received from the gps if the gps lost lock and was unable to receive any further good data.

 

Barry
VE6SBS

 

From: GPSL@groups.io [mailto:GPSL@groups.io] On Behalf Of L. Paul Verhage KD4STH
Sent: Sunday, March 31, 2019 9:56 AM
To: GPSL@groups.io
Subject: Re: [GPSL] TrackSoar

 

I'll try testing that. My D72 doesn't even break squelch, so I was thinking the TrackSoar wasn't even trying to transmit.

 

I had one suggestion to remove the comment statements and then look at debug statements. That means learning more about C for the Arduino. I can at least edit a sketch and upload it. Today I guess I'm going to learn more.

 

On Sun, Mar 31, 2019, 9:41 AM Mark Conner N9XTN <mconner1@...> wrote:

I have an older Kenwood TH-D7A that has trouble decoding packets that have a short TXD, especially when the squelch is turned on.  I don't know if the D72 has the same issues.  You can try running your D72 with open squelch and see if that helps.  If not, can the TXD for the TrackSoar be increased?

 

73 de Mark N9XTN

 

 

On Sat, Mar 30, 2019 at 7:38 PM L. Paul Verhage KD4STH <nearsys@...> wrote:

I'm testing a TrackSoar APRS tracker before near space season begins in earnest. If you haven't seen one of these, it's a small board with GPS, GPS antenna, transmitter, Arduino, and two meter antenna. It runs from 2 'AA'  cells. You program it's Audrino with your callsign and it's ready to go.

 

Anyhow, I wonder if anyone is using one as I'm having a problem with mine. I see that it has a GPS lock (the GPS LED illuminates once per second) and that it's trying to transmit ( the PTT LED illuminates for 30 seconds on and off). However, my Kenwood D72 doesn't hear anything. My D72 does decode packets from my other trackers, including a Strato Track.

 

So if you have any experience with the TrackSoar, could you let me know?

 

Thanks

Re: TrackSoar

L. Paul Verhage KD4STH
 

After an hour there still was no transmission.


On Sun, Mar 31, 2019, 5:04 PM Barry <barry2@...> wrote:

Try leaving the tracker on longer. I’m going from memory, but I believe the GPS LED is simply tied to the 1 PPS output and it may blink regardless of whether the GPS has lock or not. The first time you power up the tracker I’m guessing the so called PTT LED may remain bright until the GPS gets a lock as the tracker processor will be constantly on (ie. not entering sleep mode to save power) until lock is achieved and if the GPS hasn’t been powered on for some time and doesn’t yet have a complete almanac saved this may take up to 10 to 15 minutes. After this the GPS will be able to get a lock much faster, like less than a minute.

 

Barry
VE6SBS

 

From: GPSL@groups.io [mailto:GPSL@groups.io] On Behalf Of L. Paul Verhage KD4STH
Sent: Sunday, March 31, 2019 3:04 PM
To: GPSL@groups.io
Subject: Re: [GPSL] TrackSoar

 

Dang speech to text. The LED was on constantly for the 30 seconds I watched it. I turned off the tracker after watching it for 30 seconds.

 

On Sun, Mar 31, 2019, 2:53 PM L. Paul Verhage KD4STH via Groups.Io <nearsys=gmail.com@groups.io> wrote:

The LED was on constantly until I turned it off the only did was not blinking for 30 seconds.

 

On Sun, Mar 31, 2019, 1:17 PM Barry <barry2@...> wrote:

If you mean the PTT LED is alternately on for 30 sec’s and then off for 30 sec’s you have definitely have a problem. And although it’s called a PTT LED it isn’t really a true PTT LED, but actually monitors the processor activity and is basically ON all the time.

 

From my web page at http://bear.sbszoo.com/construction/traker/Tracksoar/V1-1.htm -

The PTT LED, although it becomes bright around the time of each transmission, actually indicates when the processor is awake and busy processing instructions which is why it's dimly lit between transmissions when the processor is only awake very briefly to check if it's time for another transmission each time GPS data is received and then brightens when it's time to make a transmission and the processor remains awake for much longer. After adding the 4th new feature this LED also becomes bright every 10 sec's when the processor is kept awake while checking the altitude and for a burst which makes it hard to know when a transmission actually occurs so a configuration setting was added that allows the PTT LED to be used as either a processor activity indicator or as a real PTT indicator that's only on during a transmission.

 

My web page also has a link to my modified firmware that gives one the option to make the LED a true PTT indicator as well as to add a number of other useful features (at least I found them useful.)

 

I haven’t worked with the Tracksoar since I wrote that page in 2016 and can’t remember exactly how the so called PTT LED behaves under certain conditions so can’t help much more than above and what’s on my page.

 

Are you sure that you replaced the jumper, or jumpers, that you removed to program the unit after adding your callsign etc. to the config file?

 

The one thing I meant to check out after trying to locate a landed payload and never hearing any further transmissions after it landed was whether the Tracksoar would continue to transmit, or not, the last good data received from the gps if the gps lost lock and was unable to receive any further good data.

 

Barry
VE6SBS

 

From: GPSL@groups.io [mailto:GPSL@groups.io] On Behalf Of L. Paul Verhage KD4STH
Sent: Sunday, March 31, 2019 9:56 AM
To: GPSL@groups.io
Subject: Re: [GPSL] TrackSoar

 

I'll try testing that. My D72 doesn't even break squelch, so I was thinking the TrackSoar wasn't even trying to transmit.

 

I had one suggestion to remove the comment statements and then look at debug statements. That means learning more about C for the Arduino. I can at least edit a sketch and upload it. Today I guess I'm going to learn more.

 

On Sun, Mar 31, 2019, 9:41 AM Mark Conner N9XTN <mconner1@...> wrote:

I have an older Kenwood TH-D7A that has trouble decoding packets that have a short TXD, especially when the squelch is turned on.  I don't know if the D72 has the same issues.  You can try running your D72 with open squelch and see if that helps.  If not, can the TXD for the TrackSoar be increased?

 

73 de Mark N9XTN

 

 

On Sat, Mar 30, 2019 at 7:38 PM L. Paul Verhage KD4STH <nearsys@...> wrote:

I'm testing a TrackSoar APRS tracker before near space season begins in earnest. If you haven't seen one of these, it's a small board with GPS, GPS antenna, transmitter, Arduino, and two meter antenna. It runs from 2 'AA'  cells. You program it's Audrino with your callsign and it's ready to go.

 

Anyhow, I wonder if anyone is using one as I'm having a problem with mine. I see that it has a GPS lock (the GPS LED illuminates once per second) and that it's trying to transmit ( the PTT LED illuminates for 30 seconds on and off). However, my Kenwood D72 doesn't hear anything. My D72 does decode packets from my other trackers, including a Strato Track.

 

So if you have any experience with the TrackSoar, could you let me know?

 

Thanks

Re: TrackSoar

Clif Brown
 


There are two versions of the Tracksoar.

They are very different designs (and run different f/w) so you need to be sure with one you have.

I've flown version one, it worked fine without much fuss.

I recently purchased version two, and am experiencing the problems that KD4STH described.

I contacted Tracksoar and they suggested I add "delay(500) to line 61 of the sketch.

That seemed to help (the led's are operating more or less like my version 1), and I can hear the squelch tripped on my handheld with PTT goes bright, but I don't hear the FSK data.

I put it aside at that point as I'm also trying to get a DIY LoRa tracker working, and I have Version 1 to use.

Be very interested if someone gets Version 2 working.

-Cliff