[aprssig] Any audio recordings of 144.390 MHz ?
Matti Aarnio
oh2mqk at sral.fi
Sun Oct 25 17:28:39 EDT 2009
On Sat, Oct 24, 2009 at 06:15:04PM -0400, Robert Bruninga wrote:
> >> Yes! Exactly, Without RSSI, counting packet
> >> decodes is a completely meaningless statistic ...
> >
> > Bob, you are again running off the tangent...
> > Instead of your feelings, I want raw received
> > audio as is.
>
> Hey, I aree with you completely. That was the purpose of my
> email, to encourage such analysis, because that is the only way
> to properly analyze the channel as heard at one location.
Good :-)
I may get an access to 144.390 channel audio _and_ RSSI on some large city
in US. A few days worth of that data will give us a good idea about how
much an underestimator my current "heard packets -> this much Erlang" code
really is. And how much can be seen from decoded audio vs. the RSSI data.
After all, audio is usually available, while RSSI is a lot rarer.
Just earlier today we turned on couple local digipeaters which are using
these estimators to report the channel Erlang levels:
Your average single radio, single antenna, 120m AAGL 90 km from Helsinki:
http://aprs.fi/telemetry/OH2RDY 2m
A dual radio, cross-band system, downtown Helsinki:
http://aprs.fi/telemetry/OH2RDK-5 2m, rx only (missing PTT wire)
http://aprs.fi/telemetry/OH2RDK-2 70cm, rx/tx, gates from 2m
The telemetry channels (since about 12 UTC today) are:
1) received data Erlang estimate
2) transmitter Erlang estimate
(does not take into account real tx head/tail)
3) count of received packets (on that radio interface)
4) packets the rx-igate did not gate
5) number of transmitted packets (digi + beacons)
The Erlang estimate is calculated in slices of 1 minute, and is
presented as highest 1 minute estimate in the telemetry interval.
Previously at channel 2 there was a 10 minute integrated Erlang
estimate but there are only 5 telemetry channels to report with...
> > That raw audio is able to supply me RAW DATA
> > to MEASURE, not your hearsay.
>
> My analysis is not hearsay. It is the logical observation on the
> function of DWAIT=0 and fratricide in the network that some are
> overlooking in their rush to endorse viscious digipeating.
So yes, observed effect is that with DWAIT=0 the network is not quite
as cognested as before it became into use. Jolly good!
With current infrastructure there may well be no better way.
> >> Unfortunately, I do not think that the APRS-IS
> >> web pages can do any meaningful ALOHA calculations,
> >> because the calculation must be done on what a
> >> single receiver hears at a single location.
> >
> > Like these ?
> > http://ham.zmailer.org/oh2mqk/aprs/oh2rdk-heard-direct.png
> > http://ham.zmailer.org/oh2mqk/aprs/oh2rdy-heard-direct.png
>
> I tried them, but the links did not work for me, but I assume
> they are exactly what we need at each Igate.
There was a hardware fault, they are available again.
> I was saying that a central site cannot make any analysis
> remotely based on other Igate feeds, but each site can make its
> own analysis and make the result available to the rest of the world,
> as apparenlty your site is doing. This works perfectly since each
> Igate knows what it hears on RF (though it does not know what it
> doesn't hear) which is the point we are both agreeing on.
My "site" are just couple static pictures I made some weeks ago while
analyzing, what these systems are able to hear. These plots are made
using local RF packet data that they log locally.
> > Note the massive asymmetry in both cases,
> > a "single number" really is not all that good.
>
> The calculated ALOHA Range should not be interpreted as a
> geographical circle, but a single unit of measure that is
> independent of topology but represents the range from the
> receive site that constitutes a full channel. And since it is
> calculated exactly the same way at each location, it reveals a
> relative figure of merit.
I will put that on my TODO/Wishlist
> >> IDEA!!! Since the OUTPUT of an ALOHA calculation
> >> at any one site is a single NUMBER, we could ask
> >> ALL IGATES to make [frequent] ALOHA calculations
> >> and INCLUDE their ALOHA RANGE in their IGATE beacon.
> >> This way, we COULD capture this information
> >> for local, regional and national analysis!
> >
> > Isn't the idea in igate/digi that it does not need
> > to know where it really is? Nor look inside the
> > packets for deep analysis like packet originator's
> > coordinates?
>
> Yes, for routine operations, but since we have Igates all over
> the nation and world, this could be an additional function they
> could perform. I assume that most Igates have some form of
> local client function and station lists, because they have to
> have a LOCAL list to know what stations are their responsibility
> to pass messages to.
>
> Shucks, it would sure be nice if EVERY DIGIPEATER also had a
> little smarts and could also report on its own RSSI.
Well, if they had access to the RSSI signal, which may be possible on
some integrated radio+datamodem system.
> That would
> give some people a clue what the digipeater is hearing on its
> input. In its 10 minute beacon it could report:
>
> "176RX, 109TX, 243 busy"
>
> ON a ten minute basis (total 600 1 sec slots) this tells us that
> 176 packets were decoded at th is site, 109 were elegible for
> further digipeating, and another 243 seconds the channel was
> busy with other collisions and non decodable traffic. Leaving
> 72 secnds the channel was clear.
You are equating time (1 second) with one packet ?
I think it is over-estimating channel utilization by 30 to 50%.
Another interpretation of "243 busy" is that out of 600 seconds, there was
243 busy seconds (and 357 free seconds.)
If a system is able to say "apparently channel is busy", it will also be
able to account "apparently channel is free." Why not report them both?
Or for that matter, account also time share on successfully decoded data.
Trouble of having too much data to report...
> This kind of info would be very helpful for analyzing the
> network. Maybe we can get some of the new digis to make such a
> report?
>
> Bob, WB4APR
More information about the aprssig
mailing list