Tracker4

Scott Miller

Administrator
Staff member
#1
The Tracker4 is now shipping, so I guess it's time to try out the new support forums! Firmware updates are going to be frequent for a while - there are still a lot of features to be added and some bugs to be squashed. If you have any questions or feedback on the T4, post here!
 

Scott Miller

Administrator
Staff member
#2
The latest manual revision is up at https://www.argentdata.com/files/Tracker4.pdf and there's a new firmware update available for download. Added a few new minor features, including an automatic NTP time sync option. The system will now also detect if the RTC oscillator has failed (these 32 kHz crystals have been troublesome in the past) and will fall back to updating the time in software - but only when the system is powered on, of course.

I'm still chasing a bug I thought had been squashed before we started shipping. The tracker will occasionally lock up with the top red LED lit. I've made some changes today that I'm hopeful will fix the problem. For the moment the watchdog timer is off (the one that resets the MCU, not the one that shuts off PTT) to aid in debugging. It'll get turned back on when I'm confident that bug is fixed.
 
#3
Thanks for all the help these last couple days scott! I'm sure we will get these Gremlins figured out. Have a feature suggestion: On the home page, where the stations digi list is perhaps you could arrange them in ascending order from newest station heard to oldest and have them time stamped somehow.

As time goes I'm sure it will become way more streamlined like that.

My goal is to phase out using APRS-IS and use the tracker 4 as the stand alone Igate/digipeater and would like to eventually be able to view a lot of relevant information on it's Digi/Igate stats. Looks great though, I know you're working hard on it.

Again I'll keep you updated on what I find out in the upcoming days.
 
#4
This morning checked the tracker and found it off. It required a safe reset again. Had to reconfigure also. Downloaded new update and opened up browser in chrome this time. Same issues with not saving data as seen in Firefox. Seems this issue is occurring with both browsers.

Set up tracker for in APRSIS and its disconnecting randomly requiring a full reboot. Attempted connection a second time to APRSIS via USB and wanted to try using the telnet via the Tera term emulator in order to observe the debug.

Was successful for about five minutes after the wifi (telenet) disconnected which also disconnected the USB port and locked up the tracker with the infamous 'solid red LED'. Couldn't get the tracker to reboot after disconnecting and reconnecting the usb. (So far I haven't found any one thing that is triggering the red LED)

After performing a safe reboot I connected to the emulator successfully. I disconnected the emulator and tried APRSIS via the USB port. I wanted to observe the tracker via the emulator using WiFi so I tried connecting via the telenet option. This again worked but only for approximately five minutes then the entire process of locking up and having to reset occurred again.

This next time I first connected just to the emulator and then the browser. Besides not being able to save and configs via the browser, the unit did turn on. I wanted to run it as a stand alone which I let it do for and hour while comparing the aprs stream via my otm3. Found is had many fcs errors and was having a real hard time both decoding packets and Igating-

The tracker lost it's port connection at 1.25 hours in. Resetting was not helpful. It required yet another safe reset. (No red LED this time)

I've also noticed there is a lot of options in the radio config and not any explanations clarifying how they function- I experimented with the receiver settings in an attempt to make the trackers RX more selective. No success.

Scott, could you perhaps educate me on the radio options in particular?

I use three radios for Aprs in the shack- FTM-3500, ICOM-281 and wouxun. I've used all successfully (mostly) with the otm3. The tracker 4 just doesn't seem to be decoding correctly- quite frankly it's probably my lack of knowledge with the radio/tnc settings on the tracker 4.

I have to do config settings thru the emulator which is a pain since the browser side is not functioning well.

Maybe my unit is internaly trashed? Perhaps? Should I send it back Scott?
 

Scott Miller

Administrator
Staff member
#5
Thanks for all the help these last couple days scott! I'm sure we will get these Gremlins figured out. Have a feature suggestion: On the home page, where the stations digi list is perhaps you could arrange them in ascending order from newest station heard to oldest and have them time stamped somehow.
That's on my to-do list. I could get bogged down for a long time making it work like a full-fledged APRS application, and I'm planning to do some more visual stuff like a radar plot showing relative locations, but right now I've got to get a few other critical features done first.
 

Scott Miller

Administrator
Staff member
#6
Maybe my unit is internaly trashed? Perhaps? Should I send it back Scott?
You can send it in if you want - I'm curious why it's been hanging with the LED on right away. What version is it showing now? I'm on 130, wifi version 38. It looks like my bench test unit ran overnight without glitches and gated about 4300 packets.

As for the receive issue, have you tried setting the RX level to its full scale, 3300 mV? You might want to make sure you're not running too hot and clipping. From the console you can type STATUS ON and it'll show a status bar at the top of the screen with a an audio level meter and percentage on the left side. I'm going to be adding an AGC option later to set the RX level automatically.
 
#7
That's on my to-do list. I could get bogged down for a long time making it work like a full-fledged APRS application, and I'm planning to do some more visual stuff like a radar plot showing relative locations, but right now I've got to get a few other critical features done first.
Understood- no problem scott
 
#8
You can send it in if you want - I'm curious why it's been hanging with the LED on right away. What version is it showing now? I'm on 130, wifi version 38. It looks like my bench test unit ran overnight without glitches and gated about 4300 packets.

As for the receive issue, have you tried setting the RX level to its full scale, 3300 mV? You might want to make sure you're not running too hot and clipping. From the console you can type STATUS ON and it'll show a status bar at the top of the screen with a an audio level meter and percentage on the left side. I'm going to be adding an AGC option later to set the RX level automatically.
Yeah I'll try taking the RX level up, I only brought it up to 2500. The update is showing the correct firmware for both. I have seen the level grid above on top of the emulator, didn't understand it's particulars much. Thanks for the info. Would hate to have to return the tracker but if it's internaly glitching than it's doing me no good.
 
#9
Alright quick update:

Been working with the Digi for about an hour. I read that the tx level is the most important- per manual. I turned both the RX and tx up to 3300. The audio meter shows full and at 99%. Now I've always been confused between the radios own audio knob selection, and the various menu driven selections for the tnc. Which one(s) are the MOST critical? The radio audio itself does for sure directly affect the audio meter. Also setting the RX below 200mv actually triggers the audio meter quite a lot... Which I assume that meter is really showing the mv they it correct?

With APRSIS-IS 32, you definitely don't want the emulator running via WiFi (telenet function) AND using the USB as the main port; Its causing the tnc to lock up and drop the port and wifi to the emulator.

Bummer, cause I wanted to monitor the tracker4 via the emulator (wifi via telenet) while running it through it's paces via APRS-IS 32. Also I really need to understand better the TX and RX functions. Scott, could you provide a quick rundown? Some of these settings I'm just not knowledgeable yet to understand.

*** The browser still is not functioning. Both in chrome and Firefox. Setup on another computer, still no joy**$

Digipeater function-. Still poor, real poor. What tests do you know of Scott, that I can run to determine the units internal health? I might have a bad one here... I know there are many teething issues here but seems like mine is acting in ways you haven't yet had occur on the bench.

Software update-. Was performed per your instructions.
 
#10
That's on my to-do list. I could get bogged down for a long time making it work like a full-fledged APRS application, and I'm planning to do some more visual stuff like a radar plot showing relative locations, but right now I've got to get a few other critical features done first.
Sure thing- was just an idea.
 

K4HG

New member
#11
Question: Is there a potential issue with very sensitive packet input connectors? At 30 mV it is audiably overdriven, at 10 it is under modulated. I've tried a number of settings in between, but only very rarely get a copy either by a nearby digi or my Kenwood 74. What I'm guessing is you use the transmitter mV parameter to scale the waveform to the DAC, so at a low enough mV value you could get what amounts to a 2 or 3 bit DAC, producing an ugly and unintelligible waveform, right? I stole too much time already from more important things trying to get this on the air so I haven't looked at it on the scope yet. It is looking like I need to give up on this old TM-733!
 
#12
Question: Is there a potential issue with very sensitive packet input connectors? At 30 mV it is audiably overdriven, at 10 it is under modulated. I've tried a number of settings in between, but only very rarely get a copy either by a nearby digi or my Kenwood 74. What I'm guessing is you use the transmitter mV parameter to scale the waveform to the DAC, so at a low enough mV value you could get what amounts to a 2 or 3 bit DAC, producing an ugly and unintelligible waveform, right? I stole too much time already from more important things trying to get this on the air so I haven't looked at it on the scope yet. It is looking like I need to give up on this old TM-733!
Good question! Right now I'm experiencing the same at 25mv. Trying to tweak it higher. Have you noticed that when it does capture a 'right next to it' packet, that it's either still touch with clipping or that the packet telemetry is cut off at totally random intervals??
 

Scott Miller

Administrator
Staff member
#13
Now I've always been confused between the radios own audio knob selection, and the various menu driven selections for the tnc. Which one(s) are the MOST critical? The radio audio itself does for sure directly affect the audio meter. Also setting the RX below 200mv actually triggers the audio meter quite a lot... Which I assume that meter is really showing the mv they it correct?
The maximum audio level the tracker can handle is 3300 mV. You need to make sure the volume on the radio is set so that it doesn't go over that. I usually aim for 70-80% of full scale with a normal packet to leave a little overhead. If you're working with a radio that has a fixed 100 mV output you'll want to set the audio level range on the tracker lower to match it. If you're hitting 99% on every packet and the RX level is already at its highest setting, you need to turn the volume on the radio down.

The USB console will be disabled when a telnet session is active. I don't really want to try to handle multiple simultaneous shells - it's going to complicate things unnecessarily. I could have an option to not make it exclusive, so you'd be able to type from both and see output from both.

KISS and telnet at the same time shouldn't be a problem. I've got a telnet session and APRSdroid running at the same time right now.

The trackers should have all been tested against a portion of the WA8LMF test CD for decoding performance before getting packed up. It sounds like you've just got the radio's volume too high for your RX level setting. I'm thinking of ways I could show that in a diagram in the manual. Once I get the AGC option set up it shouldn't matter so much.

Can you try hitting F12 to bring up the developer tools in Firefox to see if it's giving you any errors?

Scott
 

Scott Miller

Administrator
Staff member
#14
At 30 mV it is audiably overdriven, at 10 it is under modulated. I've tried a number of settings in between, but only very rarely get a copy either by a nearby digi or my Kenwood 74. What I'm guessing is you use the transmitter mV parameter to scale the waveform to the DAC, so at a low enough mV value you could get what amounts to a 2 or 3 bit DAC, producing an ugly and unintelligible waveform, right?
You're right, quantization noise gets to be more of a problem as the audio level gets lower. It's a 12-bit DAC, though, so you can get down to about 200 mV before it goes lower than 8 bits.

That's with the DAC running from its 3.3 volt reference. It can also run from an internal reference that goes down to about 1/3 of that so the DAC can keep its full resolution over a narrower voltage range, but on this board revision that turned out to be unusable - the internal reference can't be enabled because it also turns on the output pin, which is used for something else on this board. The next revision will change that. I might also add a jumper to divide it by 10 or so just in case it's still an issue.

If you're having trouble getting it low enough, you might try turning on the HT PTT option. It connects the audio line to PTT (grounded when transmitting) through a 2.2k resistor and will load the output down.

Scott
 
#15
The maximum audio level the tracker can handle is 3300 mV. You need to make sure the volume on the radio is set so that it doesn't go over that. I usually aim for 70-80% of full scale with a normal packet to leave a little overhead. If you're working with a radio that has a fixed 100 mV output you'll want to set the audio level range on the tracker lower to match it. If you're hitting 99% on every packet and the RX level is already at its highest setting, you need to turn the volume on the radio down.

The USB console will be disabled when a telnet session is active. I don't really want to try to handle multiple simultaneous shells - it's going to complicate things unnecessarily. I could have an option to not make it exclusive, so you'd be able to type from both and see output from both.

KISS and telnet at the same time shouldn't be a problem. I've got a telnet session and APRSdroid running at the same time right now.

The trackers should have all been tested against a portion of the WA8LMF test CD for decoding performance before getting packed up. It sounds like you've just got the radio's volume too high for your RX level setting. I'm thinking of ways I could show that in a diagram in the manual. Once I get the AGC option set up it shouldn't matter so much.

Can you try hitting F12 to bring up the developer tools in Firefox to see if it's giving you any errors?

Scott
Developer tool (F12) pictures emailed to you. Radio volume is at about 70%>. Should I tweak perhaps the TX levels? The tx delay is at 30. Both levels I changed to 3300. No difference. It's not decoding what THE OTM3 is right next to it.

Correction-. I have KISS thru the software (via USB) and have telenet up. Now the problem seems to be when exiting APRSIS32 first then getting a lockup/port drop. If I disconnect the emulator first then exit and then exit the software, it seems to behave. Interesting.

Now Scott when you say the USB console do you mean opening up via the drive? (My computer, clicking on the drive)
-. Sorry I lost ya there, go easy on me Scott!

Vox threshold is at 50, that really shouldn't affect anything- NOW I have heard of instances where some folks needed to turn the radio squelch off... Doesn't that just allow all the distortion and noise thru? Haven't done that with the OTM3... Am I missing that?

FCS errors are at 605-. Does that seem high to you?
 
#16
Developer tool (F12) pictures emailed to you. Radio volume is at about 70%>. Should I tweak perhaps the TX levels? The tx delay is at 30. Both levels I changed to 3300. No difference. It's not decoding what THE OTM3 is right next to it.

Correction-. I have KISS thru the software (via USB) and have telenet up. Now the problem seems to be when exiting APRSIS32 first then getting a lockup/port drop. If I disconnect the emulator first then exit and then exit the software, it seems to behave. Interesting.

Now Scott when you say the USB console do you mean opening up via the drive? (My computer, clicking on the drive)
-. Sorry I lost ya there, go easy on me Scott!

Vox threshold is at 50, that really shouldn't affect anything- NOW I have heard of instances where some folks needed to turn the radio squelch off... Doesn't that just allow all the distortion and noise thru? Haven't done that with the OTM3... Am I missing that?

FCS errors are at 605-. Does that seem high to you?
***Status up top showing (ch 1) between 35-46. Still trying to get them all as close as possible.
 

Scott Miller

Administrator
Staff member
#17
Correction-. I have KISS thru the software (via USB) and have telenet up. Now the problem seems to be when exiting APRSIS32 first then getting a lockup/port drop. If I disconnect the emulator first then exit and then exit the software, it seems to behave. Interesting.
Ok, looks like that was a problem with the CDC code. It was trying to display a banner when it shouldn't have been. I've uploaded a new version that should fix the hang. Also, keep in mind that as soon as something starts sending KISS packets to the tracker over USB it'll switch to KISS mode, and if you connect with your terminal program again you'll need to hit control-c a few times to get it out of KISS mode.

None of the TX settings will affect the decoding side of things. If your radio is at 70% volume - like you've got the volume knob cranked up 70% of the way - that's probably way too high. Try turning it down to about 1/4 and keep the RX level set to 3300.

There was a tuning option for setting the TX level with a slider but the interface was kind of a mess and that's been disabled for the moment. I'm going to try to put it in the radio settings screen later.

The VOX threshold won't affect decoding, it'll just affect when the tracker considers the channel to be busy when it comes time to transmit.

Running open squelch is fine and it's sometimes preferable since the receiver will react faster. The FCS error count doesn't mean much, especially if you're running open squelch, because it'll also increment on random noise. It does tell you that it's at least getting some kind of audio.

Something to keep in mind with the T4 is that it's very closely related to the ADS-SR2 repeater controller, and in fact the front end web stuff is identical between the two, as is all of the networking code and the whole application framework. That's why you'll see somethings like 'Transmitter 1' when the tracker only supports one transmitter - the code is designed to handle multiple radios. You'll also (for now) get two channels displayed in the status bar. And it's why the radio settings screen is still a little confused; some of the timers and units need to be tweaked for consistency between the two. There are also some commands like MODE that don't apply to the tracker and haven't been disabled yet. If you see any references to 'Cobalt', that's the internal code name for the T4/SR2 platform.

Back to the web app for a minute - is it just saving parameters that doesn't work? What do you see in the developer tools when you try? Anything? Or was that the screen shot you sent me? It doesn't seem to be getting any errors. Firefox is working fine for me here. If you turn on the debug output, when you save the general settings form it should look something like this:

Code:
W:[128169] POST: Set config data
N:[128169]                      name    Tracker4
N:[128169]                  cw_speed    20
N:[128169]                  cw_pitch    1200
N:[128169]             gps_time_sync    on
W:[128172] <134> Tracker4 config: Configuration saved.
I'm still chasing down a bug that's causing it to crash occasionally. I can tell what kind of fault it is and where it's ending up but not where the fault is coming from.

I've uploaded yet another manual revision. I've started a section on how to configure various APRS clients for use with the tracker. So far I've got a bit about APRSdroid and APRSISCE/32.

Scott
 
#18
Great info as always Scott-

Nothing shown in the developer tools for the browser. Just what I sent you. So if I were to try and leave the squelch open should I then change the squelch mode? The note next to vox threshold states not to use vox mode when unsquelched.

What is the difference between the two other modes and what would be your recommendation on a mode for open squelch?

If the vix threshold is for setting full scale then shouldn't it be at 100% for the set audio level? But then again I see it only referring to voice activity.... So that wouldn't apply to me as I use the aprs radios for that purpose only. Is this dependant on the RX mv setting?

I am indeed getting the 134 Tracker4 configuration saved message, that's good.

Turned the volume down to 1/4.

Could you elaborate on what each 'cycle' in the status menu means. Looks like it goes thru maybe four time during receive. I am now getting around 15-48% each time I beacon manually or when rarely receiving a good packet. Yeah-. I can't figure this bar out and what should be a proper percentage range.

In addition, I've also been trying to figure out how to equalize these percentages -. I doubt that actually matters as long as I stay under 99% - which is full blown distortion correct?

I'll let it run throughout the evening and check it in the morning and report back.
 
#19
**UPDATE

So took a look this morning- LED is blinking non stop- I believe its mostly red- I say that because its blinking so fast that it looks orange. thoughts? The packet reception hasn't improved. I turned the radio volume to 1/4. I think once I can get clarification on the above Scott I can probably figure out if I cave a setting I screwed up.


The good news is though that it didn't shut down/lock up and the port stayed open last night
 

Scott Miller

Administrator
Staff member
#20
Let me check out the squelch modes today and make sure that's all working right. The COR high and low options are for active high and active low squelch inputs. There should be another option that I don't think is exposed yet, and that's for carrier detect on data only.

The VOX threshold (when used) will always be less than 100%. It needs to be high enough to reliably trigger on received audio but not on squelched noise.

I'm not sure what you mean by 'cycle'. The status bar updates 5 times per second so it may be that you're just seeing it moving in steps. It shows the highest audio level received since the last update.