The Logistic Function, sometimes with modifications, has been used successfully to model a large range of natural systems. Some examples include bacterial growth, tumor growth, animal populations, neural network transfer functions, chemical reaction rates, language adoption, and diffusion of innovation, to name a few. The real world applications are simply staggering.

Because of the utility of this powerful little equation it has lead me to investigate more thoroughly how it works, and how it can be applied to novel innovations.

There have been many contributions that have led to numerous variations of the Logistic function. One that struck my attention in particular is the Verhulst Equation, sometimes referred to descriptively as the “Restricted Logarithmic Growth Function”, or simply “Logistic Growth Function”. It is used in ecology to model the expected growth of a population while taking into consideration that resources, such as food, are finite, resulting in a maximum sustainable population, called the carrying capacity. The model demonstrates an exponential growth of the population when it is significantly below this carrying capacity, but as the population approaches the carrying capacity, and resource competition increases, the growth rate slows asymptotically. The Verhulst Equation has been tested against numerous real world populations, including Seals and Elk, and has been shown to be a relatively accurate model.

Of course the Verhulst Equation isn’t limited to modeling animal populations, it has also been successfully used to model diffusion of innovation. In this sense it can be used to represent how ideas spread throughout a population. It is this particular application that was most interesting to me.

Unrestricted Exponential Growth

As with any complex idea we have to start with the basics. Whether we are talking about an idea or an organism, if it is capable of spreading through multiplying itself, then obviously the more it spreads, the faster it will spread. You start out with one, which turns into two, then four, then eight, in just a few iterations you will have billions; if there is nothing to impede the growth, then it will follow an exponential curve.

We can model this sort of growth quite simply; the rate at which new members of the population will be observed can be represented as the growth rate, G, multiplied by the population, p.

You will notice in the above equation that there is a derivative on the left hand side of the equation. The equation can therefore be read as “The rate of change in the population for each unit of time is equal to the growth rate multiplied by the current population”. If the population is seen to double each year, for example, then time would have a unit of years, and G would be 2.

Of course the equation becomes much more useful if we can get rid of the derivative and simply express the total population at any point in time. To do that we integrate the equation, while solving for p and we arrive at the following equation.

Here the variable e is Euler’s constant, and P₀ is our constant of integration which represents the population when time, t, is equal to 0.

To help visualize whats going on lets try some arbitrary values for our constants. Lets suppose the growth rate is 0.1, and our P₀ is 1. This would represent a initial population with only one member capable of replicating once for every 10 units of time that have passed. If we plug these values in and simplify we arrive at the following equation.

It is immediately obvious this is an exponential function, nothing too special about that. We can see from the graph below that the population would continue to grow exponentially and unrestricted.

Restricted Logarithmic Growth

Of course in the real world it is rare that anything will truly grow in an unrestricted manner. Space is finite, resources are finite, eventually everything must stop growing. This brings us to the Restricted Logarithmic Growth model, also called the Verhurst Equation.

Verhurst recognized that, at least amongst animals, resources are limited. When unlimited resources are available to an organism it will grow and reproduce unrestricted. However as the population grows resources become scarce. The more scarce the resources, the greater the restriction on growth and reproduction, and this effect will scale according to the proportion of the resources which are free. Therefore as the population reaches the carrying capacity of the environment then the growth rate should approach 0 in a linear fashion.

Therefore if we take the growth rate equation from before, we can add an additional term to represent the availability of resources.

In the above equation we can see that we multiply by a term that scales proportionally to the population. The term will evaluate to 1 when the population is 0, and will approach 0 as the population approaches the carrying capacity, represented as k(t). This is where the population’s growth restriction is represented.

Before we can actually solve the equation above, we have to actually know what the k(t) function evaluates to; after all we can’t perform integration on a function if we don’t know what that function is. So lets just assume the carrying capacity is a constant we will call K.

At this point we can solve for p and integrate the equation as before. This will give us an equation which models the total population as a function of time.

The above equation is usually what people refer to when they talk about the Verhulst equation, but it might help to see what it looks like with some actual values plugged in for the constants. Lets pick similar values with a growth rate, G, of 0.1, an initial population, P₀ of 1, and a carrying capacity, K, of 100.

Once we plug these values in and simplify we arrive at the above equation. It is a specific form of the Logistic Function. If we graph that we will get the following graph.

In the above graph the dotted horizontal orange line represents the carrying capacity, K. This is of course a constant with a value of 100. We can see that early on the population has what appears to be an exponential growth pattern, but as it begins to approach the orange dashed line it asymptotically tappers off. Of course as time approaches infinity (the x axis) then the population approaches the carrying capacity.

Time-varying Carrying Capacity

If we want to play with this equation a bit more we can make things more complex (and fun) by picking a carrying capacity that actually changes with time. If we go back to the original growth rate equation we can make k(t) a function equal to (t/10)+100, rather than a constant. If we do this, and keep the growth rate and P₀ constants the same as before, then we will get the following equation.

Again we can solve for p, integrate, and simplify and we will arrive at the following equation.

In the above equation Ei is the Exponential Integral Function. If you don’t know what that is don’t worry, we can just graph the equation below to get a better understanding of how it behaves.

You can see the equation behaves similarly in this graph as in the last graph. The only exception is that the carrying capacity starts at 100 and slowly increases over time. As this happens the population also increases to match the carrying capacity without ever exceeding the carrying capacity. Pretty much how we would expect it to work.

Restricted Logarithmic Growth with Injection

This is where the lessons of history end, and my own contribution begins. I was left considering the effects of a modern world and how they could be reflected in the Verhurst model.

As I mentioned in the introduction the Verhurst equation has since been used in countless applications outside of ecology models. One that was particularly interesting is that it has been used successfully to model the Diffusion of Innovation. Essentially it can accurately describe the adoption of an idea within a population. For example it can model the proliferation of linguistic changes such as the change in the spelling of a word, or even the adoption of an entirely new word.

All of this, of course, has implications in marketing where the marketing penetration of a product can spread through word of mouth alone and can therefore be modeled using the Verhurst equation. But how could we use this to also account for the effects of advertising, which can often act as an accelerant to the spreading of an idea that is still primarily driven by word of mouth. Thats when inspiration struck.

If we accept that ideas spreading through word of mouth will often fit a model similar to population growth, then advertising is a bit like artificially injecting new members into a population as it grows. The advertising acts as a jump start to the population growth, accelerating it, and magnifying the effects that would be seen from word of mouth alone.

If I could incorporate this effect into the model not only could it be used for modeling product adoption, but conservationism efforts as well. It is not uncommon for conservationists to breed in captivity and then release in the hopes of supplementing a specie’s population. In this sense it would be modeled with the same artificial injection.

In fact almost all the examples given earlier where the Verhurst model has been used in the past could potentially benefit from this addition. Consider chemical reactions; an artificial injection factor could represent the effects of slowly adding new reactants to a reaction as it progresses.

So I had to figure out where this new function might fit in. When we go back and take a look at our original differential growth rate equation we have two terms, the left hand term represented the unrestricted growth rate, and the right hand term represented the constraint on growth as the resource contention grows. So all it really takes is adding an injection factor to the left hand term. The new equation looks like the following.

You will notice in the above equation all we did was add the new injection function, shown as i(t). This is just the number of artificially injected members of the population per unit of time. By representing it as a function it can of course change over time such that we can inject a varying number of members over time.

It is important to keep in mind that this injection is still scaled by the right hand term. The more resource contention there is the less effective the injection is likely to be. If we consider the earlier example of breeding animals in captivity and releasing them into the wild then this represents the fact that if resources are scarce many of the animals released are likely to die of starvation before they have a chance to have children. In the case of advertisement, or Diffusion of Innovation in general, then it is reasonable to expect that the more people that know about an idea the harder it would be for your advertisements to reach new people who have yet to hear word of it. If Pepsi plays a commercial on TV, for example, you might expect the vast majority of people who see it to already know about the Pepsi brand.

As before if we want to play around with the equation a bit to see how the model plays out we are going to have to create some definitions for our functions.

For the sake of simplicity we turned our injection function, i(t), into the constant I, and the carrying capacity, k(t), into the constant K. This just gives us something to play with and allows us to solve for p and integrate in the following equation.

Now lets plug in some arbitrary values for our constants and see how it graphs out. Lets pick a value of 1/2 for I, 1/10 for G, 100 for K, and 1 for P₀. If we plug these values in and simplify we arrive at the following equation.

Finally, lets graph the carrying capacity and growth model as before. In the graph below carrying capacity is once again represented by the dashed yellow line, and the solid blue line is the population. We can immediately notice that while the graph still has a logistic curve to it that the population grows significantly quicker in the beginning than with the other models, but despite the injection it still does not exceed the carrying capacity at any point.

While this model has yet to be tested against real world data I am hopeful that it will provide an accurate representation of an artificial population injection in growth models. I am looking forward to see how I and others might apply this and similar models to data in the future.

As some of you may already know I am an avid Astrophotographer. Several years back I set out to photograph the Great Nebula in orion, particularly focusing on the 4 brightest stars at its center, called the trapezium. These stars produce the majority of the light responsible for lighting up the entire nebula. They are also so bright and closely spaced together that they often appear to the onlooker to be a single super bright star. My primary focus in this shoot was to be able to provide enough resolution to be able to see the trapezium as 4 distinct stars.

The image you see above is the final product of several days worth of work trying to capture and process the Orion Nebula (NGC 1976 / The Great Nebula in Orion / M42) taken on November 12th 2010. It also includes a faint wisp of De Mairan’s Nebula (NGC 1982 / M43). The shot was taken with an EQ-6 Mount without an autoguider attached to an 800mm focal length, 8" Aperture, f/4 Newtonian style Telescope. Finally my Canon Rebel T1i acted as the imager. I used a 3x Barlow without an eyepiece to increase the focal length (zoom). The majority of the shot is the result of 6 stacked 30 second 3200 ISO shots. A stack of 15 additional shots were used on the Trapezium star cluster in the center. This shot was also post-processed to improve contrast and light levels. The primary goal was to show the detail of the inner core of the Orion Nebula.

Of course in the interest of science I couldn’t just stop there. I felt it was important, and hopefully useful, to chart the various stars in the image so people knew exactly what they were looking at, as well as cross reference it with any catalogs.

In the above picture all the stars big enough to have common names have been labeled with their common names. Unfortunately none of the other stars in the picture have names so the majority were left blank.

Of course I wasn’t going to stop there. While many stars didn’t have names, at the very least, they showed up in a few star catalogs somewhere. The final image above labels every single star, no matter how faint, with the catalog identification value. Since some of the stars show up in multiple catalogs in those cases multiple identifiers are listed.

We got APEX running on a Raspverry Pi today. Wonderful new addition to the shack.

APEX stands for “APrs EXtended”; It will be a new protocol which expands on and fixes most of the issues in the older APRS protocol while still remaining backwards compatible.

APEX defines both a new protocol and a new paradigm. Since much of the new protocol will not run on existing hardware APEX also includes a Python reference implementation that will provide a full APEX application out of the box. Since APEX is backwards compatible with APRS it can fully utilize existing APRS hardware to route APEX packets across the network. Though only APEX capable stations would be able to make full use of the information in an APEX packet.

The software for the project can currently be found at the APEX GitHub page.

APEX Routing Paradigm

The APEX routing paradigm defines a few new routing identifiers in addition to the common ones such as “WIDE2-2”, and a few new behaviors on how the paths are consumed.

The problems with the current APRS model are numerous. One problem is that aside from the use of WIDE and GATE there isn’t much flexibility on how we can route packets when we don’t know the explicit digipeaters with which to specify; Using WIDEN-n is more of a sledgehammer when we need a scalpel. It is also completely ineffective at being able to route a VHF message across HF channels which may be critical during an emergency. A similar problem occurs when we consider multiple HF nets across multiple bands; as it stands right now there is no paradigm that defines cross-band digipeating paths. The closest we have is the GATE path which is generally used to only digipeat from HF into VHF. This has some limited usefulness at best. As such the initial release of the APEX reference application attempts to address these problems (though testing and feedback may change the details of the specification as described here).

Cross-band Path Routing

In order to facilitate cross-band routing the APEX protocol defines several new designators as well as includes many of the old ones. Obviously WIDEN-n, GATE, and your own callsign will behave similarly to how they behaved in the old paradigm. However the new band-specific designators will have a form of ##M### or ###M## where # represents any digit 0 to 9. The first group of numbers specifies the band ID, while the second group of numbers is the net ID and is optional. In this way the designator 30M would represent the 30 meter band as a whole (specifically any nets on that band the station is capable of). When 30M is specified in a path, a station will digipeat that packet out on any port which is tuned to the 30M band. Similarly 30M1 would specify a frequency (net) that resides within the 30M band. The list of identifiers for the various nets will be updated periodically as new nets show up. However right now 30M1 would specify the world wide FSK based APRS network residing on 10.1476 Mhz USB; similarly 30M2 would specify the world wide Robust Packet Radio based APRS network which resides on 10.1473 Mhz USB. similarly other designations would be chosen for other networks throughout the world. A complete list would have to be compiled.

Using these new designators in a path would be relatively straight forward. If, for example, you wanted a packet to take one hop, then move over to the 30 meter Robust Packet Radio channel, then move back to ordinary VHF for its last hop, and you dont care what the specific frequency on that hop, then you would construct your path as follows:

WIDE1-1,30M2,2M

Notice the last hop is just 2M with no number suffix. This is because we just want it to gate into 2M network and don’t care which frequency on that band it is gating into. As a side note the GATE specifier would actually perform the same function as the 2M specifier.

Preemptive Routing

Preemptive routing is unique to APEX and also made it into the initial release of the APEX reference implementation. With preemptive routing a digipeater can respond to certain specifiers in the path even when they are not the next hop in the path. With the cross-band path specifier mentioned above, ###M##, an optional ssid can be added to the end. If the ssid is not 0 then it specifies that the path should be treated preemptively. Essentially what that means is if it is the next hop then treat it normally however if it is a future hop you can skip all the hops in between and go straight to the hop, assuming the station is capable of operating that band (otherwise it is ignored).

For example say we wanted to create a path where I get a packet out over HF and thats all I want to do. Consider the following path:

WIDE1-1,WIDE2-2,30M-1

In this case since 30M-1 is preemptive then the packet will hop across the WIDE path but every station that hears it along the way that is capable of 30M band transmission will emit the packet on that port as well. Contrast this without preemptive paths where it would look like:

WIDE1-1,WIDE2-2,30M

In this case the packet would follow the WIDE path and even if they are capable at digipeating on 30M it will not do so. Only the very last stations that hear the packet after the WIDE portion of the path is spent will actually be the ones to digipeat over to 30M. This would cause far fewer emissions on the 30M band while still ensuring the transmitting stations are geographically spread out. In an emergency this might be a good way to send an emergency packet out.

When a path specifier has a non-zero ssid it is preemptive. The value of the ssid indicates its priority. So when there is a long path with several preemptive routes specified it is always the one that is the highest priority and when there is a tie it is always the right-most (last in the path) specifier that gets triggered. For example say we had the following path:

ECHO*,80M-2,WIDE1,30M-2,80M-1

In this case if the packet is received from a all-band capable station then it would emit the path for 30M-2 when digipeating the packet. The reason is that 2 is a higher priority than 1 and of those of equal priority the 30M-2 was the later one in the path.

Also important to note is that when preemptive pathing is executed all the intermediary paths that were skipped get dropped from the path entirely. So the above path, once digipeated, would be transformed to the following path:

ECHO*,WI2ARD-1*,30M-2*,80M-1

Another interesting twist is how preemptive routing handles the other types of path specifiers. Basically the WIDEN-n type specifiers are never treated preemptively. However specifiers which reflect the stations own callsign are always treated preemptively. callsigns, unlike cross-band specifiers do not have their priority reflected by the presence of an ssid; they are also still treated as preemptive even when they have an ssid of 0.

When there is a mix of callsign and cross-band preemptive specifiers in the same path then first the cross-band preemptive specifier is determined as before, second the right most occurrence of the station’s callsign is determined. Which ever of the two occur right most in the path is the one that wins. For example:

WIDE2-2,WI2ARD-1,30M-1

In this case the preemptive path would jump to 30M1. However if instead we had the following:

WIDE2-2,30M-1,WI2ARD-1

In this case the preemptive pathing would jump right to the WI2ARD-1 path.

APEX Reference Implementation

As part of the APEX initiative the project includes an APEX and APRS client that acts as the APEX reference implementation. It is extensible and anyone with python experience can write plugins to expand it and hook their own software into it. This allows for lots of opportunities from the community to get involved and contribute to the project.

Currently the reference implementation implements all the features I described here so far. It also includes the transmitting beacon, status, and id packets, and digipeating. So everything is ready to be played with. As new features roll out they will be added to the APEX Reference Implementation as well. It is a command line Python 3 application and you can find it on github. It is very simple to run and you just need to configure a few things in the config file to get it up and running.

Below is a screenshot showing it digipeating packets as they come in across two TNCs.

What’s Next?

There are many features that have yet to be implemented and we have some pretty lofty goals in store for APEX. A lot of this is brainstorming from the team so it is subject to change as well. But here are the ideas we have so far on what needs to get implemented into APEX and defined within the protocol.

• Ability to send a signal check packet. These will never get digipeated. Instead you send a packet which contains some diagnostic information about the antenna (HAAT, Power, gain, etc). Next any station which directly heard you will respond immediately with information regarding their own antenna information. Also if possible data will be encoded to indicate received signal strength of the received packet (on most setups this information wont be encoded). The signal test request packet will also specify if they desire the reply packet to be over the air, or through APRS-IS or both. In this way the information can be used for someone to probe band conditions as well as objectively try to configure a new antenna installation.

• When possible encapsulate all existing AX.25 packets in FX.25 packets instead, thereby introducing backwards-compatible Forward Error Correction.

• Provide throttling to prevent congestion. Packets are given priority based on several factors such as the length of the packet, and how frequent the sender sends packets, to determine a packets priority. Higher packets go through while lower priority packets get dropped. Misbehaving nodes, or out of date notes not running APEX would be potential reasons to give a packet a lower priority in addition to traffic statistics.

• Include the ability to send images and other media, potentially across multiple packets.

• Optionally request acks at the packet level. This is particularly useful when using callsign paths. Though for WIDE paths it is still useful to know what paths a packet took for diagnostic reasons and path discovery reasons. In this way an initial packet in a series can use wide but once the paths are discovered then the explicit paths can be used for the subsequent packets. This would reduce network congestion.

• Subscribe-to-callsign: a mechanism whereby a request can be sent to a normally out-of-range station to send me periodic updates to their beacon or other similar packets (comment, id). This is useful for tracking a friend when the station doesnt have internet access of their own.

• Improve or replace the IGATE system so that multiple instances of the same packet can be reported to it (with different paths)

• Rolling beacon ranges. Stations will move over to a store and forward approach. Essentially they will cache as much information about the system as possible. The longer it stays on the net the more information it should receive from distance nodes. This is accomplished with rolling beacons. Basically every station will keep track of how many times they have heard a beacons from the various stations. Any time a beacon is heard more than ‘D’ times where the receiving station is the last hop, then it will digipeat the beacon, and reset the counter. The value of D is an integer representing decay rate. A higher letter for D and stronger the decay rate. What this will cause is a beacon from a station that has been on a long time will get their beacon across the world hundreds of hops, but very slowly. Because the packets decay with distance this also wont cause a lot of net congestion. For example you might hear a beacon on VHF come from across the continent, but such occurrences would be very rare as well. So it may be exciting to follow rare DX like that. Using this system even if the network went down across the world (not an expected occurrence) it would still be possible for systems to communicate across long distance APRS links, by leveraging the stores cache of beacons every station has they can easily form a path.

• Smart routing for internet capable stations. When considering #8 combined with IGATE access it makes smart routing a possibility. Smart routing would be the process where the route of a packet to reach its destination can be discovered from the fixed stations in a region. The idea is that if the internet goes down these stations still have a cache locally of where the stations are around the world and in their area. This information can be used to create more direct route for message-type packets with a specific destination. This will significantly help congestion since these packets no longer need to try to follow WIDE type paths. Plus a system like this will be more resilient in situations where you have wide spread internet outages.

• Enforcement of certain behavioral rules for stations and to react automatically to a misbehaving station. For example if a beacon rate is too high then all beacons above the accepted rate will be dropped. This will also penalize the priority that station gets when routing its packets.

• Proper standards defined and implemented to encode the protocol version into the packets.

• Geographic routing: We want to add the ability to route packets to approximate geographic coordinates, either in an attempt to send a specific message or to transmit a WIDE message at that location to seek contact with anyone who may be actively listening.

• Better software messages for responding to various types of messaging: CQ, Bulletins, and messages need a nice clean GUI to work with or command line tool

• Delay Tolerant Networks - The general use case is to leverage moving cars for long-distance packets where latency isnt a top concern. It can transport high volumes of data long distance where normal packets could not.

• Retry packets from partial path: When a packet doesnt get to its destination, since stations will be expected to a have a large cache of packets heard, delivery can be retried by the closest node that successfully received the packet. This would make long-distance packets far more feasible.

• Mobile stations can announce stationary “home station”. Once geographic packet routing is in place then two mobile stations can stay in touch by simply knowing their route to the home station at anytime. This simplifies discovering routes that would otherwise be impossible between two mobile stations without the use of the internet.

• Formalize the use of ID packets to clearly specify the various path identifiers that can be used with the station and their effects. for example “WI2ARD/30M2 IGATE” might specify I have a station with ID WI2ARD on 30 meter robust packet radio, and it is also igate capable. This, along with position beacons, should make it possible to discover paths dynamically.

After much frustration trying to get my old KAM-XL TNC up and working I finally got it all back up a few weeks ago. For the sake of future hackers I’d like to share the steps it took to get it all configured.

First off, buy the correct cables for your radio and hook it up. Less problems to troubleshoot for you in case things don’t work right. For me both the Yeasu FT-2000 and my Kenwood D710 radio hooked directly to a single port on each radio. For the Kenwood D710 You want to attach to the DATA port on the back of the unit; for the YEasu FT-2000 you connect it to the PACKET port. Obviously each radio type has its own name for the port to use, so that part you will need to figure out for yourself.

The hard part for me was getting the radios configured and properly tuned. Most of the information I could find on the internet gave misleading and often blatantly wrong information as far as this goes. The first, and most glaring issue, is that most internet sources claim the tuning frequency for the KAM line of TNCs (which I took to include the KAM-XL) was 10.14760 MhZ USB or the equivalent LSB frequency. I prefer to use USB since the frequency is so close to the band edge and some radios will erroneously block transmission if using USB; which was the case on my FT-2000. The actual frequency you want on HF for use with the KAM XL is 10.14710 Mhz USB. For the VHF radio you will want to tune to 144.390 Mhz FM in the USA, outside of the USA the frequency may differ.

This should be enough for the radio to work, but there are a few other settings I found improved reception on the HF radio, my Yeasu FT-2000. The ideal settings for me were as follows: Attenuator off, IPO ON (no pre-amp), FLT Thru (the VRF should be turned off), R. FLT 6Khz, AGC off, Noise Blanker off, Transmit Power 25W or less. Since I see no difference when i transmit at a full 100W either way I keep it under 25W. Though for my radio I did not see any decrease in performance at full power.

For the Kenwood D710 the only important settings seem to be the squelch and the TNC setting. Squelch should be set such that you hear incoming beacons but static gets squelched when no incoming signal occurs. If you don’t do this the TNC will think the radio is always busy and will never send outgoing packets, only receive them. The TNC setting should be off such that neither the APRS TNC nor the KISS TNC are engaged. If you see any of the following on the display then the TNC is still engaged and must be turned off: Packet12 or APRS12. The number 12 may vary depending on the baud setting of the radio at the time.

Next, we want to set a few things on the TNC itself. The easiest approach is to use KISS mode, in which case none of this matters and you can get up and running right now. ui-view or any APRS software can get you up and running in KISS mode. However if you wish to use the TNC in host mode or as a standalone TNC not hooked up to a computer then you will need to tweak the settings a bit. Also ui-view can still work with the TNC in host mode (as opposed to KISS mode) but since the TNC will send out its own beacons and status packets you will want to disable ui-view from doing this or else you will have duplicate packets.

The settings of the KAM-XL you need to set, at a minimum, in host mode are as follows: MYCALL, HBAUD, and BTEXT. MYCALL should be set to the call you want to use on each port separated by a slash. So if you want no ssid on the HF port (same as ssid of 0) and a ssid of 1 on the VHF port you would do something like “WI2ARD/WI2ARD-1”. Similarly if you want to transmit out of both ports you will need to set HBAUD to “300/1200”. Finally set BTEXT to be your beacon text including coordinates (if you use a GPS attached to the KAM-XL this can get set automatically). My BTEXT for me was set to “!3955.05N/07510.06W&http://JeffreyFreeman.me”. Everything after the ampersand is the comment, this can be anything, and the data before the ampersand are the coordinates.

That’s all there is to it, your KAM-XL should now be up and running in host mode. One thing to point out though, do not expect to hear many incoming packets, a few a day at most. The KAM-XL works with the older AX.25 over FSK modulation which isnt very good on HF (though works fine still on VHF). For this reason not very many packets will get through. Luckily Robust Packet Radio (RPR) is a new type of modulation that is quickly replacing APRS on HF. While RPR is backwards compatible and will still pick up the older APRS beacons the KAM-XL itself is not capable of RPR. By moving to RPR you will notice a significant increase in the quantity of received packet from the APRS network. I highly recommend updating to a SCS Tracker (the only TNC capable of RPR) if you want the best results from APRS over HF.

Found this little gem on the bottom of the cradle charger for my Beofang.

It reads as follows:

PLACE TYPE Li-ion BATTERY CHARGER

Note: Prevent cooks meals or is injured, only battery assigns carry on the charge.

Input: DC 10V
Output: DC 8.4V 400mA

Charging

The charge completes

Bright trickling charge (battery stops using has been long) / the chareto mistake.

I’m just going to leave this here, and remember Beofang puts just as much attention to detail into their hardware as they do their English. But hey, at least their punctuation was completely correct.