I have been thinking about this too - most of the guides I’ve read miss crucial bits out and are tailored to specific use cases. I will look into this and try and get something up and running.
2 Likes
I have one set up already. It’s awaiting approval.
3 Likes
No Richard, I just use the T-Beam tracker when I go out for a walk on Winter Hill. It’s not set for WIDE digipeating, so shows only were it’s received directly - currently by 14 stations, at distances of up to 80 miles!
Looking at the APRS-IS with a /200 filter from here shows dozens of packets per minute - here’s just one minute’s worth of traffic on a map:
So trying to Gate all that to RF would run you transmitter at 100% duty cycle.
(And I see that a lot of these packets aren’t really APRS stations, just place-markers for personal hot-spots, etc.)
3 Likes
Yes. There’s a lot of un-needed stuff that adds little or no value (IMHO). How would your suggested filter look “t/pm/g3cwi-6/200” ?
2 Likes
I’ve been playing with APRSISCE which is an APRS client for Windows.
You can play with filters and watch the callsigns come in. There are some built in filters so it can get a bit confusing as to what it is doing.
m/200 does receive a lot of packets, including positions. And I couldn’t get t/pm/g3cwi-6/200 to receive anything.
2 Likes
Here’s a good explanation of APRS messaging.
The key point is that a TX-capable iGate will only transmit a packet for a station that it has heard recently. So the filter m/200 would receive a lot of packets from the internet but only transmit those to stations that are within range.
2 Likes
Yes it should - but that’s a function of the IGate client software - the Windows program has implemented it, but have the LoRa ones? I guess they would need to maintain an “MHEARD” list of locally-received stations for it to work properly.
3 Likes
I’ve just looked at the iGate source on github and it does keep a list of heard stations and will only transmit if the station has been heard in the last 30 minutes (assuming no bugs of course).
3 Likes
That’s encouraging, thanks for checking.
2 Likes
Hi @all ,
as for the ACK, its needed for some process like WINLINK connections and other ones that send and expect it.
as for the filter , I recommend as minimum “t/m/YourIgateCallsing/10”
the last number (10) is the distance in kms at which the igate would receive from aprs-is any packet for checking if it should transmit.
for crowded places 10 (kms) is fine
for places with lower igate counts , 30-50kms is fine
for really low igate counts , 100 (kms) may be needed
if you use “m/100” the igate would receive any packet (messages objects etc etc) and check if it should transmit.
using bigger than 100 is not advisable (specially in crowded places) as the esp32 may not have the speed processor to handle that much data.
11 Likes
Ok. APRS-wise, this isn’t the busiest part of the country. I’ve only seen a couple of stations get positions in through my iGate in the last week. I’ve tweaked my iGate to allow messages out, with t/m/M0LEP-10/30 as the filter (Ruardean Hill G/WB-021 is 22kms away, and May Hill G/WB-019 and Cleve G/CE-001 aren’t much further away) to see what happens…
2 Likes
May Hill is G/WB-019 - 021 is Ruardean Hill
Rod
EDIT now corrected above
1 Like
Oops. 
(Updated previous post appropriately)
1 Like
And I get an internal server error when I try clicking on either of these links. Any ideas?
Rod
BUT I still get the internal error message on all three - on more than one computer.
“Internal Server Error” is all there is.
1 Like
Looks like the SSO has crashed. 
I’ve sent a note via the contact link just in case the MT don’t already know…
1 Like
Now working OK - thanks to whoever fixed it.
73,
Rod
1 Like
The SSO servers have a base plate of pre-famulated amulite surmounted by a malleable logarithmic casing in such a way that the two spurving bearings were in a direct line with the panametric fan. The latter consisted simply of six hydrocoptic marzlevanes, so fitted to the ambifacient lunar waneshaft that side fumbling was effectively prevented. Unfortunately the marzlevanes went out of alignment and there was enough side fumbling that SSO failed.
Josh realigned the mazlevanes and SSO seems happy again.
4 Likes
Good one! 
(…and thanks)
1 Like
…and there are a few entries in the system log. Some of them look a bit like this:
Jul 7 17:09:01 M0LEP-10 CA2RXU_LoRa_iGate_1.3 CRC / CRC-ERROR / <?#001M1AFY-6>APLRT1,WIDE?$?3!%4$1/="?0iE??:?8B|;r.00V (-3mA? / -127dBm / -21.50dB / 5877Hz
…so data doesn’t always get through. There have been a couple that were less garbled, though:
Jul 7 17:09:31 M0LEP-10 CA2RXU_LoRa_iGate_1.3 RX / GPS / M1AFY-6 / APLRT1 / WIDE1-1 / -127dBm / -14.50dB / 5858Hz / 52.33910N / -2.41684E / 72.9km / Bat=-0.00V (-3mA)
Jul 7 20:39:10 M0LEP-10 CA2RXU_LoRa_iGate_1.3 RX / GPS / G8YPE-10 / APLRG1 / WIDE1-1 / -127dBm / -21.25dB / 6205Hz / 52.39358N / -1.95804E / 83.6km / SW Birmingham LoRa iGate
Edit 0530z.… but those just look like positions. I guess I also need to check for TX logs to see if any messaging activity happens. Clearly those stations are outside the 30km range specified in the filter, so my iGate should not be offered messages to pass on to them.
2 Likes
Always check the hydro-refractor in the fibre optic monochromatic harmonic synthesiser, as the heterodyne oscillator can drift out of specification. A defective schottkey thermistor in the colpitts syncotronic inverter power supply is the usual cause! (I always replace the lithium niobate capacitors with ferric silver zirconate alloy devices for better thermal stability and less RF intrusion effects.)
The gyronic warp pertubational magnetiser field stabliser holds up much better that way!
Check the Flux induction of the Magneto-capacitve reactance oscillator for proper phase synchronisation and coupling to the bichromic optotransducer.
You may have the Framzit set Cockamamie to the Motengable, causing everthing to to go Catywampus!
3 Likes