Setting up APRS for Wheeling n' Stuff

[DaveInDenver]

What about going at the other path and adding Bluetooth to your radio? I bet more effort has been put towards solving that within ham circles that you could leverage. I use serial to Bluetooth adapters, for example...

 

[satchel]

I thought about going that path as well, however I use the bluetooth to connect to my stereo to play music and directions, etc. I'm leaning towards just using aprs.fi without the serial cable connected for most of the times when I have service and just plugging it in while I am without service where aprsdroid is needed.

 

[DaveInDenver]

APRSdroid can run as an Internet client. Set the connection protocol to APRS-IS and it'll use your cell data or Wi-Fi instead of the radio TNC.

At least that way it would appear more seamless in terms of messaging. When you use aprs.fi you can get messages but it's clunky. The webpage isn't really an APRS client, rather a general front end to the APRS-IS servers. To be more fully compliant with APRS intentions when you use APRSdroid through a mobile radio like the TM-D710 or other full TNC you should set your SSID to -9, which means an two-way APRS station that's capable of receiving messages.

When you just do a dumb tracker on the air you're supposed to change the SSID to reflect that you can't receive messages. Such as KD0SAT-12. But when you connect via the Internet rather than over the air you're not constrained by the AX.25 packet definitions, which only defines 4 bits for SSID and thus the 16 number limit. On the Internet you can use any ASCII value you want for SSID and different icons will show up. These are known as objects in APRS, which is what Igates (RF-to-Internet gates), Internet weather stations, etc do.

For example I put AC0VH-i when I use the aprs.fi on an iPhone (also it puts a different note in the message and changes the client identifier). This puts me on APRS-IS feeds as a phone icon. This would be an invalid character over the air.

Or depending on the digipeater it might put it as a -9 station. ASCII lower case 'i' is decimal 105 or binary 0110 1001, so the lowest 4 bits truncated would be 1001 or decimal 9. That's why I picked it, it's almost always right regardless if I'm on RF or APRS-IS.

 

[satchel]

Ah, I didn't know I could see internet traffic via aprsdroid. That's cool. It doesn't seem to want to show my position when I click the "send position" option but otherwise that's great. I've never done a message so not sure what I'm missing there at the moment but I'm sure I'll get more into it.

 

[nakman]

@rover67 thanks again for geeking out last Friday night... we were 126.5 miles apart but able to send messages through APRS on the radios, which was kinda cool.

What is odd though is just how hit or miss it was... like sometimes it was as fast as a text on the phone. Other times it took 10 minutes, so sometimes just didn't even transmit. And it's not like we were changing settings or anything... heck I barely know how to repeat the same series of operations to transmit a message anyway. But I think you only got about half of the ones I sent... I got more like 70% of yours... they all appear in the message log though, fwiw.

If I'm being honest, I don't think message performance using the Garmin inReach is any better. Every year when I go backpacking it's always a mystery if someone will receive my text messages, even Garmin to Garmin we don't see each others' messages half the time. I know these are different things but also kinda not, as in both cases it's shooting packets around satellites right? And heck, are they even the same satellites?

But hey, 50/50 on 2 devices is a 75% chance of sending a message when I need it, right? been a while since I did probabilities...

 

[DaveInDenver]

Two-way messages are an interesting thing, especially over the air. Suffice to say the number of puzzle pieces that have to fall into place for it to work is pretty cool. If one station is an Internet station or at least stationary with a good path to a digipeater significantly increases probability of success.

One thing hams do is expect an immediate send and reply. But the packets are intended to be acknowledged, which requires a delay in sending another packet if the previous is important. So be reasonable in expectations. If you initiate too many packets that aren't getting through you're just clogging up what bandwidth you do have with lots of overlapping packets flying back-and-forth.

So you type up a message, hit send. That message is sent at 1200 baud, so if your message is 200 characters it's going to take about 1/6 of a second to send. Plus a header. Plus the delay to allow receiver squelch open. Plus an end tail to prevent the receiver from squelching too early. Means it takes about a second or two for your message to actually send on the air.

Now factor in a dozen or hundred other stations trying to use the same spectrum. If they all transmit at the same time only one wins. So APRS stations listen before transmitting to try to prevent that. But it doesn't always work. Also you never know when someone else is asking for a message to be sent and the digipeater flips to transmit.

So there's a lot of collisions in busy areas.

That's why the protocol has a built-in retry mechanism. It'll try to send a regular message 7 times (for APRSdroid). Position message only get sent once, BTW. But it will stop retrying if it gets an acknowledgement. That acknowledgement in the case of message is the receiving station having actually heard it, which needs to RX your message and send back an ACK packet, which itself must be heard by a digipeater and transmitted to you. It's a full two-way link done at half duplex over shared spectrum with probably poorly tuned radios and modems. It's frankly amazing it works at all.

If anything in the chain glitches then the packet is not acknowledged and your client will send again. And again. And again. And again. After 7 times it gives up and thinks that message was not received. But the chances are it probably WAS received and just not ACK'd.

There's a lot more (believe it or not after this screed) to this whole APRS network thing and how to increase success.

 

[DaveInDenver]

Oh, yeah, I forgot one key part about messages. If two stations are on the same digipeater then you will talk directly but if not they move across the world on the APRS-IS, meaning the APRS Internet Service. There's a bunch of backend servers around the world handling APRS traffic on the Internet. When you send a message the system doesn't just blast everything. That's would be a tremendous waste of resources.

But it *will* find you if you send a packet, e.g. that's the real reason we send all those periodic position packets. It's not supposed to stand in for your Garmin InReach or whatever. Ever notice the station info on aprs.fi shows last heard and last path?

For example...



It shows your path and the Igate that connected your packet to the Internet. So when Marco sent a message back only that one digipeater out of hundreds or thousands of APRS digipeaters transmitted the packets intended for you. If both of you are on the same digi that's where it ends. If you're not the APRS-IS knows to do the routing.

However if you had moved on or change position and couldn't hear that original digi anymore you'd never get the ACK or future messages until your next packet updates the APRS-IS routing tables.

There's a variable here when there's other digipeaters in the area who happened to repeat the packet, which is why it's important to set your 'WIDE N-n' right so you get enough local digis trying you without asking for so many that the Internet routing is paralleled with a dozen RF links across the whole West. You want the Internet to move your packets when you go beyond about 2 hops regionally, e.g. state-wide or more make the IS do the work. So this can get messy if you're ping-ponging between more than one very wide coverage digipeater.

There's mechanisms in the system to prioritize paths and eventually age your position so that eventually a digipeater forgets you if you don't use it for a while, which is why a home station is usually set to beacon itself about every 30 to 60 minutes. The Smart Beaconing algorithm also does this and reduces packet times at zero MPH to a very slow but regular period.

 

[nakman]

Well this is just fascinating... my only implication with suggesting APRS is a stand-in for Garmin is that if I'm running APRS, I'll likely be running the inReach also. And they each provide about the same benefit to me, #1 being a way to send a text to someone when I am out of cell range. And #2 providing some type of panic button should something bad happen. Garmin is obviously better at #2 because it's got a dedicated button for that, also a dedicated call center to support it. APRS still requires a little effort.. .like finding another station first, then asking if they can relay a message, etc., no different from calling mayday on FM for that matter, except that you don't need a local antenna, or repeater.

Will be interesting to see what I actually use, if any of it. Marco has a way to send phone text messages through the radio, which is kinda cool, but that's pretty easy to do on the Garmin also. I guess at some point those Garmin messages will cost me $0.50 each, I've never hit that threshold though and don't even remember what it is. Will be fun to try to message radio to radio though, still way more cumbersome than just keying up and talking but you can't deny the range!

hey @CardinalFJ60 I just found a function on our radios where we can set up APRS beacons- you can program up to 8 stations and automatically be notified when they're within a specified radius, 0-100km. page 32. I'm gonna add you at 25km and see what happens.

 

[nakman]

also Dave, I confirmed my radio is set to WIDE 1-1, WIDE 2-1. option 3 on the list below. Also how it shipped from the factory, I just learned.

 

[DaveInDenver]

Well this is just fascinating... my only implication with suggesting APRS is a stand-in for Garmin is that if I'm running APRS, I'll likely be running the inReach also.

I run my SPOT also. I only meant APRS wasn't intended to be a constant stream of position packets so you could go back and map your GPS route. Positions are supposed to come just often enough to keep you active in the system.

As far as an InReach otherwise, e.g. periodic positions and ability to message they are similar. Obviously the satellite path is usually more reliable and in fact the way those short burst data systems work (SPOTs, InReach, etc.) is an evolution of APRS in concept with a generation of evolution in the radio and networking.

When you get down to it SPOT/InReach/sat phones negates ham and APRS but it's handy to see everyone around you in a less than go to 11 method and I honestly think it would be useful to have a network controller who mans a base radio and APRS map.

There's a few cool servers on the APRS system, SMSGTE that relays cell system texts and one that relays emails called EMAIL or you can use Winlink email over APRS. You can also ping a weather server via APRS by sending a message to WXBOT. It'll send you back a NOAA NWS brief forecast over the air.

 

[rover67]

I have a question since our resident Elmer seems to be on a roll:

When Nakman and I were playing the other evening I couldn’t see him on my map on APRSdroid. In fact I could only really see a handful of stations in the Denver metro area. Is there a way to get that data “pushed” more quickly? I have the time (station signal “age?”) set to two hours and same paths as Nak on his radio fwiw. I did try to search in aprsdroid to see if I could filter and display say only the -9 stations but I don’t think it can do that. Figured that might make it more efficient.

Logging onto aprs fi online I could see him and a bunch of other stations that weren’t showing up on my truck setup.

Also thanks for the beta on the weather, I’ll have to try that.

 

[DaveInDenver]

I have a question since our resident Elmer seems to be on a roll:

When Nakman and I were playing the other evening I couldn’t see him on my map on APRSdroid. In fact I could only really see a handful of stations in the Denver metro area. Is there a way to get that data “pushed” more quickly? I have the time (station signal “age?”) set to two hours and same paths as Nak on his radio fwiw. I did try to search in aprsdroid to see if I could filter and display say only the -9 stations but I don’t think it can do that. Figured that might make it more efficient.

Logging onto aprs fi online I could see him and a bunch of other stations that weren’t showing up on my truck setup

A digipeater and an Igate are distinct functions that aren't required to be the same station and often are not. Drilling down even further there's receive-only Igates and bidirectional and different types of digipeaters such as high level and fill-in.

This is only to say that what your network looks like locally can differ from what APRS-IS thinks it looks like. Don't assume it should be a perfect 1:1. For one there's several Igates feeding into APRS-IS and you're just one station hearing just some small amount of the same traffic. You might agree closely with the Igate and/or digipeater closest to you but that's about it.

If not, first thing is simple, make sure you have done all you can do to dial in your antenna and location. Can't decode anything if you can't hear it in the first place. Digital radio is subject to the RF limitations, e.g. strong enough to have signal-to-noise to decode information.

Next is your modem. Most likely high level digis and primary Igates will have tuned their devices so it lands on you to do the same. In the case of canned APRS like an FTM-400 there's not much you can do since Yaesu already did what they did.

Since you're running an external TNC (modem) you have more flexibility. Put another way you've been given more than enough rope, now it's up to you to not hang yourself...

You want to geek out, start down the path to understanding pre-emphasis and de-emphasis, modulation index, deviation, twist, network timing.

N8UR's Packet Radio Pages

Basically you might need to tweak levels and parameters to decode more. It's easier to optimize receive than transmit, so you got that going for you.

 

[rover67]

OK, great info, I will start to read more, lots of keywords here.

 

[DaveInDenver]

Since we've gone and opened the can, might as mention that there's a test CD that exists.

http://wa8lmf.net/TNCtest/

This has a bunch of things useful for testing packet stations. There's a lot of very good general information on his website, too.

 

[Skidoo]

Since we've gone and opened the can, might as mention that there's a test CD that exists.

http://wa8lmf.net/TNCtest/

This has a bunch of things useful for testing packet stations. There's a lot of very good general information on his website, too.

Dave,
Great meeting you Friday night. Thanks for the info that I will be using to tweak my setup.
Have a Kenwood V71, TinyTrak4 w/ BT to a tablet running APRSdroid.
Has been a great combo for me, one band for voice the other for APRS.

 

[nakman]

nerds, this content reminds me of a video I shot at Cruise Moab in 2007. I didn't have youtube at the time, the file was saved as a .wmv. Well I uploaded it to youtube today, for our pleasure. I can't believe that was 16 years ago.


View: https://youtu.be/Ou4Q54xrM_A

 

[DaveInDenver]

The continuing saga that is APRS clients. I know @rover67 has had issues for a while that we could never figure out.

Due to a very generous benefactor @ScaldedDog I was able to upgrade the antique Droid running Android 4 to a much improved phone that's just at the tail of technology running Android 10.

Well I must apologize to Marco for doubting, I ran into the same speedbump and could not get the previously working APRSdroid to function. Same Bat app (version 1.6.2b), same Bat maps (V3 of Mapsforge). No joy.

I came across a build that seems to have solved the offline issues. The Play Store version has been broken for a long time so you will have to side load the app. Depending on your security setting this may upset your phone.

I zipped a version "aprsdroid-gl-2022-02-07.apk" that is working on my new truck phone/terminal. The zip file is 1.9 MB and will expand into an APK. It should say it's still 1.6.2b in the "About" page but will have the "2022-02-07" after it.

Android does not like unverified installers and probably will not let you install this by default. If you can't work around it post up and we'll see if we can walk you through it. I'm not an Android expert to tell you exactly the steps so a web search may be more expedient, though. It's a matter of hitting the right check boxes to allow it.

You will still need the map. That is too large to attach (The Colorado-Utah one alone is 481.7 MB) so that might pose a bit more of a problem. You must use old V3 maps and OpenAndroidMaps no longer shows them.

However, the Wayback Machine seems to have an archive from 2018. Testing these is TBD since I can't tell their version at this point. But I assume being prior to 2019 that they are V3 or older.

https://web.archive.org/web/*/https://ftp.gwdg.de/pub/misc/openstreetmap/openandromaps/maps/usa/*

Now I should also say that I do not really know what broke in Android between 4 and 10 and I cannot say that this app will work for anything newer either. YMMV. Let us know what you find.