Open ARDF

It seems that any rewrite of IARU Region I rules to permit the use of smartphones would necessarily touch on Part B, Appendix 1, paragraph:

“T4.2 The use of satellite positioning devices is allowed provided they do not contain digital map of the terrain (“nonmapping” devices).”

This will be a sensitive issue for those competing with satellite navigation devices, and ARDF receivers incorporating them. But those who maintain that the use of satellite positioning systems is equivalent to past innovations in ARDF receiver technology and running apparel are missing the point. The fundamental difference is that the use of geolocation receivers (GPS, GLONASS, etc) introduces navigation information that is derived from a source located totally outside the ARDF course and its transmitters.

From its inception, ARDF has allowed only these sources of navigation information:

o Official Course Map
o Compass Direction
o Received Radio Signals (from course transmitters only)

Those three navigation data sources constitute the foundation of ARDF: the fundamental elements of navigation in that sport. Until recently, all other navigation data sources have been absent (if not specifically banned) from the sport of ARDF.

Region 1 has changed all that with the introduction of paragraph T4.2. That paragraph has been interpreted by some to mean that, aside from the display of digital maps of the terrain, all use of GPS data is permissible.

Satellite geolocation systems derive position information from signals emitted from orbiting satellites. Such outside-the-course information, whether displayed on top of a terrain map, used in the calculation of bearings, distance calculations, the display of followed track, or any other navigational purpose, constitutes a new navigation data source. A source that can be used to substitute for map reading and compass headings, and is available even in the absence of an active “fox” radio signal.

With the addition of paragraph T4.2 to IARU Region 1 ARDF rules the sport of ARDF is now defined by four navigation data sources:

o Official Course Map
o Compass Direction
o Received Radio Signals (from course transmitters only)
o Received Geolocation Service Signals (from satellites)

Not all innovation involves the addition of new data sources. Improvements to ARDF receiver designs to decrease their bulk, or improve their performance, still allow those receivers to pull in information only from the received course transmitter signals and nothing else. Digital compasses sense the Earth’s local magnetic field in order to derive a heading, just like mechanical compasses. Course maps displayed on video screens would add convenience, but no additional map data. Cleats on running shoes improve traction for running, but don’t add a new mode of locomotion.

Satellite navigation receivers are different.

The addition of satellite signals to the definition of ARDF might be good, bad or indifferent depending on one’s perspective. But regardless one’s opinion of the benefits, the fundamental change made to ARDF should not be ignored or glossed over. And any rewrite of paragraph T4.2 should involve the rules’ authors’ careful consideration of what data sources should be included in the sport. If the door is open to allow the use of satellite navigation signals, are there other external sources that should be added as well? Is there justification for excluding anything?

But it should be recognized that although almost all smartphones include satellite navigation hardware, ARDF-approved apps will be able to include, or exclude its use so as to adhere to the rules regardless the fate of satellite-derived navigation in the sport.

Should-Be-Asked Questions intended to help clarify issues related to smartphones and similar personal electronic devices running approved ARDF apps are presented below.

Won’t smartphones allow competitors to place phone calls, use maps with GPS, etc. to gain an unfair advantage?

Smartphone hardware does indeed provide support for cellular network access, maps, and other features that, if permitted, would radically change the nature of ARDF. But the hardware features are only accessible through software programs that provide the user access to those functions. An app that does not provide access to the cellular network, or maps, or any other prohibited functionality will prevent the user from accessing those features for as long as the app is running. Apps approved for use in ARDF would not provide access to prohibited functionality.

Won’t a competitor simply be able to close an app and make phone calls, etc.?

Yes, an app can prevent access to prohibited functions only so long as that app is running in the foreground, and maintains control over what the user can access. But approved apps would be required to record events such as the app’s closure, phone calls being answered, and any circumvention of the app such as placing it in the background. The easiest way to record such events is to create log files that reside on the smart device. Those same logs would be required to be submitted immediately after completing a course, by all competitors carrying a smart device in a competition. Failure to provide a continuous log file, or any circumvention of the app indicated in a submitted log, will result in the disqualification of the competitor.

So a competitor carrying a smart device must be required to run the same approved ARDF app during the entire time on the course, from start to finish. Failing to do so will result in disqualification.

In an emergency, a competitor could elect to close the approved app in order to place a phone call for help for him/herself or another competitor. That is an important benefit of allowing cellular-enabled devices to be used on the course. And in the event that a smartphone is used in an emergency situation, the Jury could rule to allow such use in that instance. Such emergency use should be quite rare.

Won’t analyzing all those log files require a lot of effort on the part of organizers?

Before smart devices and approved apps are permitted for use in major ARDF competitions, an automated system for log file submission and analysis should be implemented. Approved apps could automatically and wirelessly upload log files to a server (or local PC) for analysis. The server could automatically analyze all submitted log files, and notify organizers of any suspicious events contained in them. Organizers and/or the jury would only get involved if suspicious log data is found; This should be a rare event.

What about jailbroken phones, hacking, and counterfeit apps running on competitors’ devices?

The devices would not need to be approved for ARDF use, only the apps that run on them. So jailbroken phones, and side-loaded apps, are not an issue. If an approved app is run on a jailbroken phone, or has been sideloaded onto a device, it is still an approved app, and will only provide permitted functions, and will record logs containing evidence of any app circumvention.

Since it is the apps that are approved for use, measures must be put in place to authenticate the apps running on competitors’ devices. Again, the log files could be used for this purpose. Approved apps could be required to support a registration procedure at time of installation, that embeds into the app a unique public key. A unique identifying tag encrypted by the public key (a signature) would automatically be included within the log file submitted by each app-carrying competitor. If the tag in a log file decrypted by the associated private key were found not to match the tag associated with the registered app, that would indicate that an inauthentic app was used and that competitor would be disqualified.

Hacking the authentication system should be made difficult, but extreme measures need not be employed. As long as it is much harder to hack the authentication system than to sew a hidden pocket into a uniform for stashing a disallowed mapping GPS device (for instance), a cheater will choose the easier path.

That all sounds like a lot of work, isn’t it too great a burden to place on organizers and the Working Group?

Yes, the burden of implementing authentication measures, log file submission and analysis tools, and all other components of the overall support system for approved apps, should lie squarely upon those who would utilize the system: the app-carrying competitors and the app writers.

The only burdens imposed upon event organizers and regional authorities should be the creation of rules, approval of systems implemented for authenticating apps, and the adjudication of issues that might come up. That degree of support should prove small relative to the potential benefits.

Who wants to use smart devices and approved apps anyway? What would they add to the sport?

Were a blanket ban on all communication devices not in place, we would almost certainly see smart devices in use at ARDF events today. But without rules governing their use, it is not worth the effort to develop apps and a system to support them, because there is no assurance that the developed apps will ever be allowed to be used in competition.

Modern smartphones and similar devices can provide a vast array of functions relevant to ARDF. From a simple compass app providing magnetic headings, to a graphical user interface providing access to all receiver functions, satellite positioning information (if permitted), background track recording, real-time position reporting, and control point arrival registration. Almost anything imaginable within the rules can be done, including enforcing the rules themselves, with approved apps and a system to support them.

With the rise in popularity of smartphones, approved apps should lower the cost barrier for entry into the sport. Since many participants will already own the most expensive hardware component (the phone itself) little more than a receiver front-end and a suitable antenna will be required to fully participate in the sport.

Cell phone communications access, provided by the smartphones carried by competitors, can add to the sport’s safety.

Welcoming ARDF-app programmers worldwide will help bring in new sport supporters and participants.

In short, there is a lot to be gained from the use of smart devices and approved apps. But it all starts with the rules.

Who would approve ARDF apps?

App approval could be done in any number of ways. But one approach that would help focus the responsibilities on the app users and developers, would be the authorization of App Approval Authorities (for lack of a better name) who would take on the responsibility of developing a complete system.

Applicants from the community of ARDF app users and developers might be allowed to apply to a Regional ARDF Working Group for recognition as an ARDF App Approval Authority. A group so designated would have the responsibility to develop a complete app authentication system for approved ARDF apps: a system that applies to app development, validation, dissemination, and use in competition. The only real “authority” of such an Authority, would be that of defining exactly how the app approval process works under their system. The only reasons for such groups to be officially recognized by the WG, is to avoid chaos, and to afford those Authorities some standing when they request reasonable accommodation at ARDF competitions for testing their systems, etc.

An App Approval Authority would be responsible for all of the work and investment involved in designing and implementing a system to approve and authenticate ARDF apps. It would also be responsible for providing documentation to the Regional ARDF Working Group demonstrating that a proposed system works correctly, reliably, securely, and does not impose excessive demands on organizers.

What would be the approval process for a candidate ARDF app?

App approval would necessarily be a component of an authentication system. It should be the responsibility of an App Approval Authority to define an app approval process that passes muster with a Regional ARDF Working Group.

Exactly what form an app approval process takes remains to be seen, but some of the elements of the approval process might include:

1. App authors being required to certify that their apps provide users access only to functions and features allowed under the latest release of official ARDF rules.
2. Apps being required to successfully complete a validation process proving that they support log file creation, encryption and submission requirements. (Apps might be required to incorporate the binary of a custom authentication library, providing them with the ability to successfully register and submit logs.)
3. Apps would probably need to be officially submitted to an Authority for approval well ahead of their use at sanctioned events, to allow time for validation and any required rework.
4. Apps might be required to be open source, so that no hidden functionality could be concealed in them, and a wide community could examine them in detail.
5. Apps’ binaries might be compiled and submitted to app stores by an App Approval Authority, rather than by the app authors, in order to ensure the integrity of the submitted binaries.

How do the rules need to change in order to allow approved smart-device apps for ARDF?

Using the Region 1 rules (version 2017) as a baseline, the following changes to Part B Appendix 1, Section T4 should suffice:

T4.2 All personal electronic devices (including satellite positioning devices, and radio receivers or other devices with integrated navigation or communication functionality) are disallowed unless their capabilities are inherently limited to provide no navigation assistance or communications functionality except for the following:

o Short range device-to-device digital communications providing connectivity between permitted devices carried by the same competitor (e.g., Bluetooth, WiFi, or NFC data link between a receiver and a display screen.)

o Long-range digital communications providing connectivity specifically authorized by event organizers (e.g. real-time competitor position reporting over a cellular network.)

o Display of digital official competition maps provided by the event organizers, that can be used in lieu of a paper map.

o Compass direction.

o Non-graphical position information (e.g., latitude and longitude text data stored to a track file) that is unavailable to the competitor during the competition.

Any device capable of providing navigation or communication functions beyond those listed above is subject to T4.3.

T4.3 Personal electronic devices, receivers, and other devices that would otherwise be banned under the rules shall be permitted to be carried by competitors and team officials during the competition if both of the following conditions are met:

o Any device capabilities banned under the rules are not used, and are effectively disabled or unavailable at all times and in all situations where those capabilities are disallowed.

o Evidence of compliance (e.g., continuous log files) to establish that banned capabilities were not utilized must be provided in accordance with an App Authentication Procedure administered by an App Approval Authority designated by the Organizing Society, or as directed by the Organizing Society.

Note 1: the wording above is intended to maintain the ban on smart devices until App Authentication Procedures and App Approval Authorities come into existence, or an Organizing Society decides to establish their own procedures. The terms App Authentication Procedures and App Approval Authorities will also need to be defined in Part A section 1.

Note 2: the wording above is intended to allow an Organizing Society that wants to implement its own app authentication procedures for a particular event to do so. Not all competitions necessarily need to have the most stringent level of rules enforcement. An Organizing Society might choose to simply spot check logs randomly, or only if an infraction is reported or suspected.

Note 3: T4.2 above lists those functions that are allowed, rather than attempting to describe every conceivable function that might be disallowed. This approach should result in a shorter and simpler list, and forces us to consider what should be permitted on a case-by-case basis.

Note 4: Some additions to the list of permitted functions in T4.2 will probably be required in order to permit commercial “non-mapping” satellite positioning receivers as currently permitted under IARU Region 1 rules, if their use is to be permitted under Region 2 rules.

The goal of Classic ARDF is to find all the transmitters required for your age/gender category in the least-possible amount of time. Period. Full stop. End of story. If you can accomplish that feat, then you should always be pleased with your performance: only your physical limitations kept you from doing better, so you need only improve your strength and endurance.

But with five transmitters to locate, there are 120 (5!) fox-order permutations you can take on your journey from Start to Finish. Choosing which of those 120 routes to follow is key to minimizing your time.

It is tempting to assume that the route with the shortest total length will result in the shortest-possible time. But that is true only if you can run at maximum speed regardless of gradient and obstacles, and can locate transmitters with equal ease whether they are on the air, or silent. So there are at least three factors that contribute to your total time:

o Total route length (shortest is best)

o Ease of traversal (easiest running is best)

o Timing of arrival (arriving to within “striking distance” of each transmitter when it just starts its 1-minute transmit period is best)

The first two factors (total route length, and ease of traversal) are readily understood, though not always easy to gauge using just map and signal readings. The third factor (timing of arrival) is less obvious, and often overlooked in the calculation of best-possible route, but no less important when performing route-choice calculations.

To illustrate the role of timing of arrival, it can be helpful to imagine the case where total route length, and ease of traversal, play no part. Consider a perfectly flat landscape with no obstacles to avoid. Now pretend that you are the “Usain Bolt of ARDF”, and can cover the distance between any two points on the course in two minutes or less (roughly two transmit periods for a fox). Even Usain can’t do that? Then make yourself the Roman god Mercury instead.

Since all routes are equally runnable, and you can arrive at any two points in a 2-minute time interval, your only concern is to have the transmitter you are chasing be on the air at the moment you find it. You are a Roman god, but that only makes you fast, not omniscient – so the transmitter must be on-the-air in order to “sniff it out”, unless you are simply lucky and find its flag off cycle. Lucky is good too, of course, but harder to perfect.

Like all your competitors, you start the course from the Start when Fox #1 begins its transmit cycle. Feeling fresh, and with your lightning speed, you traverse the distance from Start to Fox #1, finding it in the middle of its second transmit period at minute 6, 5.5 minutes into the competition. With the bearings and signal strength readings you took during the first 5-minute transmit cycle, you have a good estimate of the approximate locations of all four remaining foxes; accurate enough that you can identify locations that would place you within a 1-minute sprint of each one.

So the question is: in what order should you attempt to find the remaining foxes? There are 24 possible permutations. Let’s examine two of them.

You’ve got 30 seconds before Fox #2 begins to transmit, so let’s examine the choice where you take it next. You head in the direction of Fox #2 and travel in that direction for 30 seconds before it begins to transmit. You use its signal to guide you as you run, but one minute later you arrive within final sprinting range of Fox #2 just as it goes off the air. Now you must wait four minutes for Fox #2 to come on the air again so you can sniff to its exact location. Suppose you find Fox #2 the next time it transmits during minute 12, at 11.5 minutes into the competition. Following the same strategy you select Fox #3 next, and with similar results you locate Fox #3 at 17.5 minutes. Fox #4 then is found at 23.5 minutes, and Fox #5 at 29.5 minutes. After a 1-minute dash to the finish your total time is 30.5 minutes. That’s good enough to beat most mere mortals, but could you have done better?

Let’s look at another route order. Suppose standing at Fox #1 at minute 6, you had instead decided to head toward Fox #3. You would have traveled for 90 seconds before Fox #3 began its second transmission at minute 8 into the competition. You would be assured of arriving to within sprinting distance of Fox #3 after traveling 120 seconds, and you still would have 30 seconds of transmit time before Fox #3 goes off the air. Chances are good (at least 50:50) that you will find Fox #3 before the end of minute 8. Suppose that you succeed, and then choose Fox #2 for your subsequent destination. You will start to travel from Fox #3 toward Fox #2 at the start of minute 9, and arrive within sprinting distance of Fox #2 by the start of minute 11, about one minute before Fox #2 comes on the air. After waiting one minute you then will locate Fox #2 during minute 12. Then you will choose Fox #5, which you are likely to take during minute 15. Then you’ll find Fox #4 at minute 19. Even if it takes you 2 minutes to dash to the Finish from Fox #4 your total time is about 20.5 minutes. By choosing more optimum timings of arrival, you succeeded in shaving 10 minutes from your time. Good enough to beat all but Neptunus Equester.

The example above illustrates the benefits of factoring in transmit timing to determine an optimum time of arrival. Minutes can be saved when choosing the route with the best timing advantage, from two or more routes that are otherwise similar in length and difficulty.

 

It seems apparent now, after countless schematic revisions, and several PCB respins, that it would be nearly impossible to beat a smartphone or small tablet to serve as the user interface on a high-end ARDF receiver.

Now that ARDF rules allow for GPS receivers to be carried on competitions, the logic for using a smart touchscreen device is especially compelling. Smartphones almost all include a host of useful and ARDF rules-permitted components and peripherals:

• A bright colorful touchscreen display
• GPS
• Digital compass
• Power supply
• 3-axis Accelerometer
• Audio amplifier and stereo earphone jack
• Powerful processor, ample memory, and an advanced operating system

What more could one want?

One might request a little bit less, actually.

Here’s the rub: Virtually all smart devices that include GPS, also contain cellular radios. Also, smart devices support mapping apps, including apps that display digital maps of the terrain. Devices providing those features are banned from ARDF competitions conducted under current Region 1 rules, because they could be used to unfair advantage.

So a receiver that incorporates a smartphone for its user interface would be banned from use in the bi-annual ARDF World Championships, and many other competitions held around the world every year.

The situation is slightly different in Region 2 (The Americas) where rules come into existence for a short time only, materializing some months prior to each competition. Then they disappear, like an apparition, once the competition has ended. During their short lives, Region 2 rules much resemble Region 1 rules with certain changes introduced specifically for the competition to which they apply. In theory, one might petition for a specific exception to be made for smartphone use at Region 2 events, but it is an exercise that must be repeated for each event, with no guarantee of success.

This situation is a shame. Apps can be designed to preclude the use of banned functionality. Apps can also record if they are closed, placed in the background, or otherwise circumvented. Thus, if an app logs all such events to a file, that log file could be submitted as proof that no banned activity occurred on that device.

But with no assurance that smart-device apps, and devices utilizing them, will be permitted for use in championship events, there is little incentive to develop them.

ARDF rules in all regions should be altered to allow smartphone use, on the condition that only rule-abiding apps are used, and that usage logs from all smartphones used by competitors are made available for review.

Being a card-carrying citizen of Region 2, I will start my quest for a smartphone blessing with this hemisphere’s powers that be. But my hopes are not high: given the ephemeral nature of my home-region’s rules, any changes are likely to be short lived.

The Benefits of Smarts

It might not be apparent what benefit there is to adding smartphones and similar smart personal electronic devices to the sport of ARDF. Radio direction finding has been practiced for decades without such devices, so why should that change? Some arguments for smart electronics in ARDF are summarized below.

They Can Make a Great ARDF Receiver

Smartphones, tablets, watches, and similar highly-portable computing devices offer highly-integrated, intuitive, reliable and configurable user interfaces: all features we would love to find in ARDF receivers. Adding all those features to a receiver would be very expensive, and a “from-scratch” receiver built to contain them would be prohibitively expensive for most of us. But almost all smart devices provide short range wireless connectivity that will allow them to be incorporated wholesale into a receiver design, allowing a smartphone be the interface. Since many ARDF competitors, and would-be competitors, already own a smartphone they already own the most expensive components of a high-tech receiver. They need therefore only purchase or construct the cheaper “front end” and wireless connectivity components of the receiver.

They Facilitate Emergency Communications

Most smart devices will allow the placement of phone calls and text messages at venues with cellular connectivity. The more competitors carrying smartphones the better can be the response to an emergency. Non-emergency use of such communication functions must be prevented of course; more about that below.

They Reduce the Device Count

Most smart devices feature GPS/Glonass satellite geo-positioning, a technology already permitted under Region 1 rules. Competitors who cannot afford a dedicated positioning device (or a receiver with that feature) can utilize the smartphone they already own to record their track, and gain access to permitted positioning features.

Since most smart devices include 3-axis digital compasses, there is no need to carry around a magnetic compass when your smart device has one already. That is one less item to carry out on the course.

They Attract New Participants

One of the alluring aspects of ARDF is its unique blend of athleticism and technology. Those who enjoy software development will find smart devices an entry point into an exciting new sport.

They Can Simplify Events and Future-Proof the Sport

The capabilities of smart devices today open new opportunities to simplify the sport for organizers. They could be used to remotely monitor the positions of competitors on the course, and to broadcast safety alerts to competitors in the event of hazardous weather conditions. They could be used as time registration devices at foxes. Potentially, much of the administration of ARDF events could be automated through the broad use of smart devices in the sport, making events run more smoothly for both organizers and competitors.

Smart devices will get smaller and more capable over time. Though no one can predict exactly what the future will bring (new battery technologies, heads-up displays?) by allowing advanced consumer electronics to be used in ARDF, we can ensure that those advances will be more available to enhance the sport.

Preventing Abuse

The obvious concern about allowing cell phones to be carried during competitions is that they might be abused: competitors might use them for communicating with teammates, or they might run map applications that would provide them with a competitive advantage. But such concerns can be readily addressed using a combination of technology and policy.

The opportunity for abuse could be virtually eliminated if the rules allowed smartphone devices to be carried by a competitor only under these conditions:

1. The device is used to continuously record an activity log from the time of receiver impoundment to arrival at the finish line.
2. An approved application (app) is used for log recording.
3. The file containing the recorded log is submitted to the organizers immediately after the competitor completes a course. Failing to do so would result in disqualification.

Approved Apps

Approved apps should be required to be made freely available for all to download, and more importantly they should be required to be open source so that the whole world can know the app’s true capabilities and limitations.

In order to receive approval for use in ARDF competition, apps would need to limit access to only approved functionality, and record a timestamped log file (that could include track information) with a record of certain device actions: the app being placed in the background or closed, any outgoing or answered incoming calls, etc. Apps are indeed informed of such events, and can log a record of their occurrence.

To avoid disqualification, a competitor’s log file would need to be submitted within a few minutes of arrival at the finish line. The log file could then be analyzed automatically on a server to confirm that the app ran continuously. Any suspicious logs would be flagged for review before official results are announced.

Rogue Apps

The use of rogue apps (those that mimic approved apps while providing access to banned functionality) could be prevented with the use of a registration and authentication procedure – similar to the registration of commercial software purchased and downloaded over the internet. The registration procedure could be automated, and administered by a technical committee appointed by a regional ARDF working group or hosting organization. Authentication at the finish line could likewise be automated, and performed wirelessly, with little or no human involvement. Technical details of the registration and authentication processes will need to be worked out and implemented before smart devices are allowed to be used in sanctioned ARDF events. And once in place, the system would require only routine maintenance by the technical committee, minimal oversight by organizers, and would ensure with a high degree of confidence that an approved app was continuously running on a device from the start to the finish of a competition.

Keeping It Simple

Non-sanctioned competitions, practices, demonstration events and the like need not require or support any form of authentication, or log file submission. The degree of rules enforcement should be commensurate with the the level of competition. Simply requiring competitors to use only apps meeting the “functionality” requirements of approved apps might be good enough for most low-stakes competitions. Full app approval, registration and authentication procedures might only be necessary for championship-level events. But having the regional rules spell out what functionality is and is not approved will provide needed guidance for all levels of competition.

Bottom Line

There is no way to prevent all forms of cheating. But it can readily be made very difficult to use an unconcealed smartphone running an approved app in a manner that provides an unfair competitive advantage. This should allay any concerns about permitting the use of approved apps on smart devices during a competition. Better yet, the use of smart personal electronic devices running approved apps could help improve the sport, enhance safety, and even identify and prevent certain types of rules violations.

 

 

 

 

By adding GPS positioning to the receiver another cool feature also becomes possible: automatic magnetic declination adjustment.

NOAA provides some pretty cool software called The World Magnetic Model, or WMM. The WMM models the Earth’s geomagnetic field with a high degree of accuracy, and given a Lat/Lon position the WMM will provide the geomagnetic declination for any location on earth.

Given the magnetic declination, the receiver can adjust compass bearings to provide true bearings. Which might not be so desirable in ARDF, since most orienteering maps are rotated to magnetic north, eliminating the need to adjust for declination at all. But there are other advantages.

When calculating direction of travel from GPS-derived location data, some very useful information can be derived from great circle trigonometry equations. For instance, the direction of travel (course), direction between two known points (course between points), and other useful information. But, such calculations result in directions with respect to True North, not Magnetic North. Here’s where the WMM comes in. When you know the declination for your current location, you can adjust the GPS-derived data to obtain magnetic directions.

Suppose you head off in a particular direction of travel from point “A”, say 30° magnetic (M), which is the strongest signal direction toward the fox at point “F”. You run for 250 meters, but trees and other objects force you to divert your path from a straight line, resulting in your current location lying off of the straight line between points A and F. Because you are no longer on that line, the direction that you now need to travel to arrive at point F is no longer 30°M. The processor in your receiver can determine the correct direction to run (desired course) using your current lat/lon position, and the estimated location of point F. But the calculations would be in relation to True North. But with an accurate magnetic declination provided by the WMM, the processor can easily convert and display the calculated direction in degrees magnetic, allowing you to steer by the direction provided by your compass (mechanical or digital).

Floating point math libraries will be needed for the WMM and for great circle calculations. But an AVR processor with 128KB of flash should be sufficient to provide the needed program space, with room to support other receiver functions. With no hardware support for floating point (no floating point processor) the calculations are going to be relatively slow. But even an 8 MHz processor clock speed should allow the calculations to keep up with the GPS position updates, and to appear to the user as being almost instantaneous.

 

It had been a while since I last read the Region I ARDF Rules documents. So I was surprised recently when I came across this paragraph in Part B, Appendix 1:

“T4.2 The use of satellite positioning devices is allowed provided they do not contain digital map of the terrain (“nonmapping” devices).”

This rule, as written, would appear to allow the following:

A system of devices incorporating a GPS receiver, that is capable of showing the Start position (recorded by the competitor while at the Start), estimated locations of foxes and finish beacon (based on bearings and signal strengths from GPS-derived locations) and their actual positions once found, along with one’s current location relative to all those points, and the track from the Start to the current location. Such a system could also support the placement and display of waypoints that the user sets while on the course, or even prior to the competition. The only thing that must be absent from such a system is the map overlay, which is not allowed under paragraph T4.2.*

But even without the map data, such a system (readily implemented with existing technology) fundamentally changes the character of the sport. The advantages provided by a “featureless map of critical positions” affords a huge edge to the user, and is counter to the nature of a “map, compass, and radio” sport.

Paragraph T4.2 needs to be changed to disallow satellite positioning devices with graphical displays, and those integrated with other equipment capable of displaying graphical information.

Preserving the nature of ARDF requires that competitors receive no navigation-related information from any source outside a regulation map, a compass, and a DF receiver. Perhaps an argument can be made for utilizing satellite-based devices for calculating and displaying distances between points, like a high-tech measuring wheel. It even seems desirable to encourage GPS for recording track data for post-competition analysis – such data if mandated, and collected by organizers, could even be used to prove or disprove “following” and exclusion zone incursions.

But paragraph T4.2 must be modified to prevent ARDF from becoming a form of geocaching with radios, in which competitors eyes are glued to their display screens as they run toward satellite-determined waypoints.

* A crassly-literal interpretation of paragraph T4.2 could even allow the actual transmitter locations to be preloaded into the satellite positioning device, along with vector position information of roads and trails, enabling the device to provide turn-by-turn navigation instructions to a competitor. Disqualifying a competitor for such use would require appealing to the “fair play” provisions of the rules, but that argument could be made only if the pre-loaded data were somehow discovered by organizers. Competing while in possession of such a capable device is clearly permitted under paragraph T4.2, provided that it does not contain a digital map of the terrain.

I noticed in some product descriptions at AdaFruit.com the following:

“The RTS pin (as of Arduino IDE v18 this will work perfectly for uploading to ‘inos)”

More experimentation is needed to determine which versions of AVRdude will twiddle the RTS pin. But it appears that an FTDI cable (like this one: https://www.adafruit.com/product/70) should work for automatically resetting the microcontroller when bootloading, without any need to modify the cable.

Regardless the experimental results, I will change the schematics to allow either the RTS or DTI pin out of the FT232R to be connected to the reset line through a 0.1 uF capacitor.

[Update 25 May 2017: AVRdude version 6.3 has been tested and shown to reset the processor using the RTS pin. So no modifications to the FTDI cable are required: a 0.1 uF capacitor from pin 6 of that cable to the RESET line will allow AVRdude to automatically reset the processor prior to bootloading.]

It came to my attention recently that there are AVR USB bootloaders available. For example: https://github.com/baerwolf/USBaspLoader

The page linked to above describes a firmware-only bootloader that runs on AVR processors, including the ATmega328P. Being firmware only, it does not require any USB hardware, other than a USB jack of course. It does essentially what a UART-based bootloader + an FTDI USB-to-UART interface IC does: it allows one to plug the device into a USB port on a PC in order to bootload software updates onto the target processor. A USB bootloader is generally an inexpensive solution since it does not require the FTDI chip or any other USB-related interface hardware. It is also available for free under the GPL.

The USB bootloader requires:

• 2k of bootloader flash memory.
• Crystal-controlled processor clock running at one of the supported frequencies.

Cost Considerations

Adding a crystal would add $0.50 to the current design, but would also require utilizing two of the port pins currently assigned to other tasks. The edge-triggered interrupt would require one more port pin. The shortage of port pins could be offset by including a port expander IC for an additional $1, plus some additional flash program space for software to support the port expander. Increased PCB space for the added components should also be considered: but it should be roughly the same as that occupied by an FT232R component and its ancillary circuitry, so we can consider board space to be a wash. The difference in current drain should also be negligible.

The FT232R FTDI USB-to-UART interface costs about $4. The UART RXD and TXD lines will still be needed for the Linkbus, so there is no impact to port pin count by adding the FTDI part.

It does appear from the above analysis that the BOM cost could be reduced by ~$2.50 by using a firmware-only USB bootloader instead of the FT232R FTDI USB-to-UART interface. Potential savings could be more if the project were to move to a more capable processor (more flash and port pins) for reasons unrelated to USB bootloading support, since doing so might eliminate the need for a port expander.

Bottom Line

From a pure BOM cost standpoint, going with a USB bootloader would likely result in a net savings greater than $2, and perhaps more than $4 if circumstances result in the needed processor port pins being available.

The USB firmware-only bootloader would require allocating an additional 1k of flash to the bootloader, and it is unclear right now whether the project can afford that.

There are non-recurring costs, such as software development time, testing and debugging, and schedule impact to consider. But the option to use a firmware-only USB bootloader solution should be kept in mind as we look for ways to optimize the design for cost savings.

Other Considerations

Although the USB firmware-only bootloader could replace the UART-based bootloader for uploading new software, it would not replace the UART for serial communications. Both the Linkbus and PC control functions are needed during normal device operation, not just during bootloading. The bootloader runs at start-up only, so USB Bootloader or not, we will continue to need the FTDI chip, or an FTDI cable, in the receiver and transmitter applications.

In a previous post I brought up the subject of cloning: allowing transmitters (and receivers) to configure one another by attaching a serial cable between them. In that post I mentioned the use of a “null modem” cable. The null modem cable would simply swap the RXD and TXD lines running between two connected devices, thereby connecting RXD to TXD, and TXD to RXD and thereby allowing the devices to communicate with one another.

We could, instead, have the transmitter designated as “master” swap its own RXD and TXD internally. Then we could simply use a standard cable for cloning. The processor does not provide a means for swapping RXD and TXD, so this functionality would need to be designed in. It could be accomplished using a 2-channel double-throw analog switch, for example. A binio line on the processor would then control the analog switch.

Designating a transmitter as “master” might be accomplished by holding down the pushbutton switch for five seconds while the transmitter is powered up. A master would swap its own RXD and TXD lines, and then periodically poll for any connected slave devices. Transmitters would, by default, power up configured as slaves. Slave devices will recognize the polling message sent by a master, and upon receiving the polling message will coordinate with the attached master to receive cloning data (clock sync, sport event type, start time, etc.).

It seems that approach would make things very simple for the user, avoid any confusion about cables, and would require a minimum of fuss.