I have been on holiday for a week, so had to turn of the MB7UBP APRS I-gate to meet the shut down terms of its licence. M3SXA provides such good coverage of North London that I am not sure it was missed too much.
I used aprs.fi to look at my track after driving home (up the M20 from the Channel Tunnel and round the M25). I was surprised to see that there were some serious problems with the paths. This was backed up when a Kent I-gate owner, M0RXW enquired on the aprsig email list to solve the problem. |he group came up with an interesting solution – it seems that Alan, G3RJI’s new bi-directional I-gate, MB7UUE, is translating local internet packets to RF. I have no problem with this (*if* it is limited to very local packets) but, Alan has a great location and a high gain antenna giving him a large RF footprint and therefore high channel occupancy. This meant that timing of packets was being disrupted as the I-gate had to wait for a free slot on the air to TX a packet queued from the internet. As we have reasonable I-gate density around the perimeter of London the overall effect was to cause my position to jump around on the map.
For example
Time 1; M0BPQ-9 heard by M0RXW and gated to the internet at position X. Time 1: The channel at MB7UUE is busy so the position X received via the internet packet is stored until the freq is clear
Time 2: M0BPQ-9 Heard by M0RXW and at position Y and gated to the internet
Time 2: Channel clears at MB7UUE and the stored packets (including M0BPQ-9’s the out of date position X) are sent to RF
Time 3: The MB7UUE packets are gated back to the internet by M0RXW.
I used aprs.fi to look at my track after driving home (up the M20 from the Channel Tunnel and round the M25). I was surprised to see that there were some serious problems with the paths. This was backed up when a Kent I-gate owner, M0RXW enquired on the aprsig email list to solve the problem. |he group came up with an interesting solution – it seems that Alan, G3RJI’s new bi-directional I-gate, MB7UUE, is translating local internet packets to RF. I have no problem with this (*if* it is limited to very local packets) but, Alan has a great location and a high gain antenna giving him a large RF footprint and therefore high channel occupancy. This meant that timing of packets was being disrupted as the I-gate had to wait for a free slot on the air to TX a packet queued from the internet. As we have reasonable I-gate density around the perimeter of London the overall effect was to cause my position to jump around on the map.
For example
Time 1; M0BPQ-9 heard by M0RXW and gated to the internet at position X. Time 1: The channel at MB7UUE is busy so the position X received via the internet packet is stored until the freq is clear
Time 2: M0BPQ-9 Heard by M0RXW and at position Y and gated to the internet
Time 2: Channel clears at MB7UUE and the stored packets (including M0BPQ-9’s the out of date position X) are sent to RF
Time 3: The MB7UUE packets are gated back to the internet by M0RXW.
The overall effect on the internet map is the M0BPQ-9 travels from X to Y and then back again!
What is there to learn form this? The main issue is to set your “ignore dupes received with n seconds” setting at the correct level if you are gating Internet to RF. Perhaps this needs to be longer for Internet sourced spots than it is for ones generated on RF? Secondly, perhaps I beacon too frequently when mobile? I will revisit my smart beacon settings to look at this.
This is certainly not a criticism of Alan and his efforts to get more activity back onto RF (which I applaud), but an interesting example of the pitfalls faced by this system. I am happy to report that once Alan realised what was going on the resolved the problem quickly, so well done that man.
This is certainly not a criticism of Alan and his efforts to get more activity back onto RF (which I applaud), but an interesting example of the pitfalls faced by this system. I am happy to report that once Alan realised what was going on the resolved the problem quickly, so well done that man.
RSS Feed