|
Re: Tile Set Storage
#poll-notice
Lynn Deffenbaugh
I'm not aware of a tool, but since I'll likely be writing an
importer (tree to MBTiles), it's almost a a no-brainer to write
and exporter (MBTiles to tree). Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
On 8/25/2020 11:22 AM, Rob Giuliano via
groups.io wrote:
|
|
|
|
Re: Tile Set Storage
#poll-notice
Rob Giuliano
I have share Tiles with other programs, but REALLY, REALLY like the MBTiles storage. I'd prefer sharing MBTiles storage files with other apps, but can't control what others do. Is there a tool (assuming external) for extracting the tiles from the MBTiles that would allow sharing the trees when needed? Robert Giuliano
On Tuesday, August 25, 2020, 11:05:56 AM EDT, Lynn Deffenbaugh <kj4erj@...> wrote:
For those that may be wondering where this poll is going, I'm trying to work out how to integrate MBTiles storage into APRSIS32. I'd really like to cut and switch and auto-convert all existing tile storage to MBTiles databases, but I cannot do this if tile sets are shared outside of APRSIS32. At the same time, I'm still working on using IPFS to distribute
(meta)tiles that are not immediately needed, like prefetches. I
have this (mostly) working in an upcoming version of
TestHost(APRSISMO), but of course only for my tile server,
although I've got an idea of how to support it for the OSM tile
servers as well. Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
On 8/25/2020 11:02 AM, Lynn Deffenbaugh
wrote:
A new poll has been created: How attached are you to map tile storage in an OSM-compatible file hierarchy? Do you share tiles outside of APRSIS32?
1. Very attached, I share multiple tile set trees with other
programs. Do not reply to this message to vote in the poll. You can vote in polls only through the group's website.
|
|
|
|
Re: Tile Set Storage
#poll-notice
Lynn Deffenbaugh
For those that may be wondering where this poll is going, I'm trying to work out how to integrate MBTiles storage into APRSIS32. I'd really like to cut and switch and auto-convert all existing tile storage to MBTiles databases, but I cannot do this if tile sets are shared outside of APRSIS32. At the same time, I'm still working on using IPFS to distribute
(meta)tiles that are not immediately needed, like prefetches. I
have this (mostly) working in an upcoming version of
TestHost(APRSISMO), but of course only for my tile server,
although I've got an idea of how to support it for the OSM tile
servers as well. Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
On 8/25/2020 11:02 AM, Lynn Deffenbaugh
wrote:
|
|
|
|
Tile Set Storage
#poll-notice
Lynn Deffenbaugh
How attached are you to map tile storage in an OSM-compatible file hierarchy? Do you share tiles outside of APRSIS32?
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Mitch Smith
First off, apologies to everyone for the overly large photos posted above! Looks like my lost post finally appeared.
Demetre, as long as you have the radio set up to pass the GPS data out, then absolutely. In fact, when our radio club helps with race events, instead of my TM-D710G, I've used my TH-D74 connected to my Windows tablet over Bluetooth so I can see my location (speed, etc.) as well as the location of other stations while out on the bicycle race course. It's been very handy to have the wireless setup with the TH-D74. —Mitch Smith, N7USU
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Hi Mitch,
Can APRSIS32 see the TH-D74's GPS? 73 de Demetre M0SUY
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Mitch Smith
I went and checked both devices I am running APRSIS32 on and wouldn't you know, it says at the top of the window what I used for the port setting; KWD710(APRS).
 
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Mitch Smith
I guess it didn't like my previous reply as it didn't post. I finally noticed it says what the port setting is at the top of the window (I was looking for anything labeled KISS). I double checked both Windows devices I use this radio on. Both are set to KWD710(APRS). Give that a shot.
—Mitch Smith, N7USU
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Rob Giuliano
If (*@ has a KISS option I'd set it there, and start with Simply(KISS) as it removes all Open and Close commands and expects the radio to be in KISS mode on start. Check the port log and if you see missing <C0> (or something like that), then you know the radio is not in KISS mode and you will need to place it in KISS mode. If not, Mitch will have to look at his port settings >Menu > Configure > Ports The box should say the {name}(KISS) or {name(Simply(KISS)). Answer I would say is self explanatory. Robert Giuliano
On Monday, August 24, 2020, 10:15:27 PM EDT, Mitch Smith <pxls2prnt@...> wrote:
Sorry, I can't figure out how to check that. I set this up a couple of years ago, so I'm going off memory when I say "KISS" sounds familiar.
—Mitch Smith, N7USU On Aug 24, 2020, 19:56 -0600, Arnold Harding. - KQ6DI <kq6di@...>, wrote:
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Mitch Smith
Sorry, I can't figure out how to check that. I set this up a couple of years ago, so I'm going off memory when I say "KISS" sounds familiar.
—Mitch Smith, N7USU
On Aug 24, 2020, 19:56 -0600, Arnold Harding. - KQ6DI <kq6di@...>, wrote:
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Arnold Harding - KQ6DI
Mitch,
Is the Port in APRSIS32 set for "Simply(KISS)" or "KISS".
Arnold, KQ6DI
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Mitch Smith
Okay, I did some searching on my radio as well as my laptop. As a disclaimer, these are the settings I use for my setup. Your mileage/use case may vary from mine. This is what I have set for use with both APRSIS32 as well as connecting my TH-D74 to a Raspberry Pi for Winlink (Pat) use, so I don't know if you need all these settings set the same, but I imagine you do for use with APRSIS32.
These are the MENU settings on my radio for it to connect over Bluetooth and report my location. etc:
In APRSIS32, on the port I have the following settings checked/filled out:
Once you have that all set up make sure you have the radio TNC on and set to APRS 12. If you haven't already, you should be able to now connect the radio to the PC over Bluetooth. Hopefully this can at least get you heading in the right direction. Sorry if there is any confusion. Feel free to reach out with any questions or if you need any clarification on anything. —Mitch Smith, N7USU
|
|
|
|
Re: Bluetooth w/ Kenwood TH-D74
Mitch Smith
I do have my TH-D74 connected over Bluetooth. When I have a minute, I'll log in and see if I can get the details and pass them along. That is, if someone doesn't beat me to it.
—Mitch Smith
On Aug 24, 2020, 18:19 -0600, Arnold Harding. - KQ6DI <kq6di@...>, wrote:
|
|
|
|
Bluetooth w/ Kenwood TH-D74
Arnold Harding - KQ6DI
I did some searching, but I don't think I found it...
Is there a known procedure to connect a TH-D74 with Bluetooth to APRSIS32?
I think my unknown part is any special "port" parameters, but all help appreciated.
Arnold, KQ6DI
|
|
|
|
Re: Store Map Tiles on microSD Card?
Charles Jessee
Just what I needed - thanks!
|
|
|
|
Re: Store Map Tiles on microSD Card?
Rob Giuliano
You can store the map files anywhere you want. You can run multiple instances of APRSIS32 at the same time, and use the same map files. If you already have mapfiles and want to move them to an SD card: 1. Close APRSIS32 2. Copy the Maps folder or the OSMTiles folder to the new location and move (or copy) into the new folder location Be sure the location includes the APRSIS32.osm file 3. Copy the path from path bar in Windows File Explorer (File Manager) so it is correct 4. Go back to the APRSIS32 install and edit the APRSIS32.xml 5. Use the Find function to locate each OSM.Path areas in the XML for teh map files you moved. There should be at least 2: a) The first one you come to is the default path b) And any that start with <!---TileServer[#]--> 6. Paste the path you copied into these location BUT you must change "\" to "/" in the path you paste. On the first 'fix' of "\" to "/" copy that and paste in the other locations. 7. If using OSMTILES.mbtiles, be sure to change the path before this filename. That's it. Your paths have been updated and when you open APRSIS32, it should read from the new location Robert Giuliano
On Sunday, August 23, 2020, 7:30:41 AM EDT, Charles Jessee <cbjesseenh@...> wrote:
Maybe you can’t?
|
|
|
|
Re: Store Map Tiles on microSD Card?
Charles Jessee
Maybe you can’t?
|
|
|
|
Re: RF to IS (Igate Question)
Tim Choldas
Good Afternoon All,
Wow! You folks replied with some awesome information. I really appreciate it all.
A few points to answer a few questions.. The igate in question is KC9WCJ-10. I'm located in Chicago. We have a fairly busy APRS system here with many digis. My goal in setting up the igate was to relieve some network congestion from the busy ones. Although
I know it's not a race, like KJ4TX said I am more so curious about how much I am truly contributing. I do understand that even if I'm not uploading as much data to the servers as others, I'm still providing redundancy and actual 2-way service for messaging. I
currently am just running it through Direwolf as an RX-only gate for testing.
What prompted this question is looking at other igates in the area, as VE6SRV did. Specifically, the two closest ones which are AB9FX and N0LSR-1. Just by looking at the "iGate'd packets" graphs for the gates, it appears they upload around 10 and 40 packets
an hour, respectively. For my station, most hours I get none (especially when looking at the "RF packets heard first" graph). I found this strange considering I have fast internet and a stellar antenna setup with some great height.
From what I've gotten out of these responses, it seems like I'm doing everything right on my end. As K5DAT said, it seems like the latency in uploading to the IS is where the difference comes from.
I will do some more toying around with selecting different servers but otherwise will just go ahead and run it as planned. My goal is to have it on battery backup and solar by the end of the year, so if nothing else I will be providing some redundancy.
Thanks again for you replies everyone! Glad I found the group.
Tim
|
|
|
|
Re: RF to IS (Igate Question)
Max
Not all of the APRS-IS are created equal. Some are faster than others and some have faster internet connections. Aprs.fi and findu.com don't always agree either and it depends on which servers they happen to be connected to. If you happen to be connected to one of the servers that aprs.fi is connected to it might show that you igated a packet whereas if you are connected to a different server it could show that someone else igated that same packet because it took a few milliseconds longer to get there and gets discarded as a duplicate. My igate gates very little most days. But the other igate seems to go down a lot in which case mine takes over. Always good to have a backup igate For me running an igate from home is a problem since I only have one antenna that is up 65FT so I no longer have a good antenna for voice. And even if I did have another antenna up high there would be the problem with desense having multiple radios on VHF. I also have a satgate and a aprs igate on an alternate frequency so I have tuned my main digi/igate to transmit very little so that the other radios don't get desenced (is that a word?) as much. Max KG4PID
On Saturday, August 22, 2020, 12:33:03 AM CDT, timcholdas@... <timcholdas@...> wrote:
Hello All! Just downloaded and set up the software for use as an RX/TX Igate. Wow, what a wonder program! For as many features as it has, it really works so well and is very intuitive. I am using Direwolf as a software TNC from my Yaesu radio hooked to a vertical at 70 feet. I'm hearing a ton of stations (verified by selecting RF only for both the map view and scroll). Unfortunately, I'm barely uploading any to the IS per aprs.fi. Maybe 1 out of every 100 received are being uploaded to the IS. From what I understand, if packets are duplicated, the first one takes priority and the others that are received by servers are disregarded. I'm wondering how/ why the other Igates are beating mine in uploading to the IS. Is direwolf slower than hardware based TNC's? I tried the rotate.aprs2 server as well as noam.aprs2. Everything is working fine per se, just seems to not upload nearly as much as it receives. How can I "speed it up"? I've been a long time APRS user and am wanting to give back to the community by adding some coverage. 73 all, Tim
|
|
|
|
Re: RF to IS (Igate Question)
James Ewen
Tim, One thing that would help is including your callsign so that we have a chance of helping you understand your local RF environment. It appears that your email address is your name, and your name is fairly unique (ie not Smith or Jones), so a search on QRZ.com gives me a callsign of KC8WCJ. It looks like your igate is KC8WCJ-10. https://aprs.fi/#!call=a%2FKC9WCJ-10&timerange=3600&tail=3600 aprs.fi is showing that there are 13 other stations gating traffic to the APRS-IS within 40 km of your location. So, you are competing with all those stations in the race to get packets to the APRS-IS first. But as others have said, putting an APRS infrastructure component on the air isn't a competition. In fact putting APRS infrastructure on the air is something that needs to be done with planning and forethought. Putting a digipeater on the air needs to be thoroughly researched and planned before one should be making the decision to put it in place. Digipeaters heavily impact the RF network by resending the packets back into the RF network. I-gates are less of an impact on the RF network due to the fact that they are mostly a listen only device. Only when there are messages destined for a local RF station from a remote station will the i-gate push traffic to RF. Having too many i-gates in an area can cause a bit of traffic congestion when they all try to push the same remote traffic into the overlapping coverage area. But for the most part, there's not a lot of IS-RF messaging happening. So, if the purpose of putting an i-gate into service is to try and "win", you've got your work cut out for you. Probably the easiest way to "win" is to disable all other i-gates for 50 miles or so. Arson works well, but it is frowned upon. Seriously, you are not alone in wondering why your i-gate isn't gating everyone around you. You have stated that you understand the race conditions, and the anit-dupe filtering, so the issue you are facing is the delay in your station. That is a factor that is contributed to by every component between the RF spectrum and the APRS-IS network. I wouldn't bother trying to tweak every component to try and "win the race". it's not important. What is important is not the number of packets that you have gated to the APRS-IS, but the fact that you have gated packets to the APRS-IS. This page https://aprs.fi/info/?call=KC9WCJ-10 can show you all the stations that were "heard" by your i-gate station. The fact that aprs.fi labels this list as "Stations heard directly by KC9WCJ-10" is perhaps where a lot of people get hung up. It really should say "Stations heard directly by KC9WCJ-10 that managed to get to the APRS-IS first, and therefore not get killed by the APRS-IS duplicate packet filters". You can see another view of the same information here: https://www.aprsdirect.com/details/statistics/sid/3018703 You can also look at the graphs of what your station is doing... You can click on one of the callsigns in the list and have a look at the raw packets from that station to see that your i-gate was able to move those packets to the APRS-IS. You can see all the rest of the stations acting as i-gates as well. 2020-08-22 00:01:24 MDT: KD9OAJ-9>TQUX9Q,WIDE1-1,WIDE2-1,qAO,KC9WCJ-10:`sK7l{M>/`"5v}_% 2020-08-22 00:02:07 MDT: KD9OAJ-9>TQUX6T,WIDE1-1,WIDE2-1,qAO,KC9WCJ-10:`sK4m\|>/`"5x}_% 2020-08-22 00:02:51 MDT: KD9OAJ-9>TQUX6U,WIDE1-1,WIDE2-1,qAR,AB9FX:`sK<0x1d>m 7>/`"5w}_% 2020-08-22 01:14:22 MDT: KD9OAJ-9>TQUX6Y,WIDE1-1,WIDE2-1,qAR,WA9SGF-2:`sK<0x1d>l!`>/`"5D}_% 2020-08-22 02:08:45 MDT: KD9OAJ-9>TQUX6Y,WIDE1-1,WIDE2-1,qAR,WX9O-3:`sK<0x1d>l!#>/`"6)}_% 2020-08-22 08:54:35 MDT: KD9OAJ-9>TQUX6X,WIDE1-1,WIDE2-1,qAR,KD9KAF-1:`sJ~l"q>/`"6C}_% 2020-08-22 08:57:32 MDT: KD9OAJ-9>TQUX6Y,WIDE1-1,WIDE2-1,qAR,KD9KAF-1:`sJ~lI\>/`"5s}_% One of the key things you need to keep in mind is that there is probably a lot of competition on the RF network between stations. APRS by it's design does not attempt to eliminate packet collisions. They happen all the time. By having multiple receivers available, you have multiple chances to be able to copy the packets on RF. This station above was on N Nagel Ave, just south of the Kennedy Expressway, not far from your house when you gated these packets. Is that because your station finally won the timing race, or was it because your station was the first station to get a clear copy of his packets? There may have been packet collisions happening that corrupted the packet reception at other local i-gates, but due to proximity and FM capture effect, your station managed to copy the full packet, and was able to gate it to the APRS-IS. Had your i-gate not been operating, it is possible that a local fill-in digipeater would have acted upon the WIDE1-1 path element, and then another i-gate might have copied that packet, and pushed it to the APRS-IS. Just as likely, it may not have happened, and those packets would have never made it to the APRS-IS network. You can't know for sure. We do know for sure however that some combination of events and conditions meant that your i-gate helped these two packets from this station get to the APRS-IS network. In areas of high APRS traffic, we can see people putting up digipeaters with little regard to the impact they have on the RF network. The "more is better" mentality kicks in when people see that their packets aren't making it to the APRS-IS, when in fact the issue is that there are too many packet collisions happening. Adding another digipeater compounds the issue, by increasing the number of packets on the air. The addition of more i-gates on the other hand can help in a situation like this as they generally are listening and not retransmitting packets. Lots of i-gates end up masking the overcrowded RF network by capturing local RF packets and forwarding them to the APRS-IS. Trying to fix an overcrowded APRS RF network is almost impossible. It's like herding cats. You need to educate people, get them to listen, understand the issues at hand, and then finally commit to actively work on correcting the problem. Most of the source of the perceived problem is people not seeing their packets on the APRS-IS. They will increase power, increase path lengths and increase their beaconing rates in an attempt to "fix" the problem. By having a lot of i-gates listening and gating packets to the APRS-IS, this "fixes" that problem, and perhaps keeps some people from increasing power, increasing path lengths, and increasing beacon rates. If they are shown to be successful with low power, and a short path, perhaps they will back off, and subsequently reduce their impact on the network, which in turn leaves more room for others, and reduces the number of collisions on the RF network. So while your station might not be winning the race every time, you are still helping to push packets to the APRS-IS. Say "Hi" to Roger and Steve! That's a pretty busy block for amateur radio! James VE6SRV
On Sat, Aug 22, 2020 at 11:41 AM Rich <rich@...> wrote:
|
|
|