Month: May 2017

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.

This post concerns the Open ARDF Equipment Project, which is utilizing the Receiver Development Platform, both of which are being developed together.

With the basic components for serial communications and bootloading identified and verified experimentally, it was time to take another look at the schematic. Only the transmitter schematic has been updated, but as far as the USB/FTDI changes are concerned, the same circuitry will go into the receivers as well.

Since changes were being made to the schematic anyway, it seemed like a good time to examine the transmitter’s DC-power control circuitry. Below is a summary of the transmitter schematic changes that were made, and the features those changes support. Schematics have been posted.

DC-POWER CHANGES

Master On/Off Switch – A single SPST switch was added. Turning it off removes all LiPo/Li-Ion battery power going to the transmitter, while still allowing the battery to be charged via USB.

Direct Processor Power – The processor is continuously powered directly from the LiPo/Li-Ion battery as long as master power is turned on. There is no provision for powering off the processor except via master on/off.

Processor Power Control – The processor is given the means to shut down all power to every part of the transmitter, except for the processor itself. Thus the processor is in full control of current drain, and should be able to bring the total current drawn below 1mA by shutting down all devices under its control, and putting itself into a low-power sleep mode.

Processor Wake-Up – Even in a deep-sleep low-current mode, the processor can be awakened by an interrupt received from the real-time clock. The processor can schedule an alarm time (e.g., competition start time) at which to be awakened.

Antenna Disconnect Protection – Provision has been made to automatically shut down all power to the transmitter (except to the processor) in the event that the antenna is disconnected. This will prevent the transmitter from being damaged by operating into an absent antenna, and is also intended to be the primary way to turn on/off the transmitter when it is deployed or collected: just plug in the antenna and you’re all set.

USB-to-UART CHANGES

The following features are supported by the FTDI circuit changes applied in the schematic:

Processor Power from USB – Even if the master power switch is in the off position, connecting the transmitter to a USB power source will power up the processor. This way it will always be possible to bootload, or change transmitter settings, via USB even if the transmitter is powered off.

FT232R Device Optional – The builder can decide whether or not to populate the FT232R USB-to-UART IC. The option to instead use an “FTDI Cable” (like this one) is supported by the inclusion of a 6-pin male header.

USB Compliance – Circuitry has been added to ensure that the transmitter draws no more than the USB standard-specified current and prevents excessive surge current.

LED Data Indicators – Red and green LEDs indicate when data is flowing on the serial data lines.

Cloning – It will be possible to “clone” transmitters by connecting their serial ports using a “null modem” cable. This will allow any transmitter to be designated as “master”, and by connecting it with another “slave” transmitter will synchronize the slave’s clock, and configure the slave to operate of the appropriate frequency and sport mode. This should eliminate the need for a Control Head, or a PC, in many situations once a single transmitter (the master) has been configured.

Hardware UI

This transmitter design incorporates a simple interface for the user: a push button, an LED, and a power switch. Additional feedback to the user can be accomplished via radio, by having the transmitter send pico-power transmissions (with the power amplifier turned off), that can be monitored up to a few meters away using a handheld receiver. The intent is for these to be used for basic configuration settings (such as “fox number” and activity type), and to trigger status feedback from the transmitter.

The serial interface should make it easy to configure any setting, including “call sign”, clock synchronization, automatic start time, and every other function and feature the transmitter provides. A program running on a PC/Mac/Ubuntu will provide a simple and intuitive graphical user interface, or menu-driven format. In a future version, an app running on a smartphone could provide the interface and configure the transmitter conveniently over WiFi. The button and LED is for those times when a computer is impractical or unavailable.

 

This is just a note to all, and to remind myself:

Are you having difficulty getting your ATmega to reset properly using the external Reset pin? Do all the other resets (watchdog, brown-out detect, and power up) work just fine, but the processor always locks up immediately after a negative pulse on the Reset pin? Have you been using debugWire to flash the processor or to debug?

This might be the answer you seek: Note that if debugWire is enabled, the external reset will not function properly: so check to make sure you have disabled debugWire before attempting to reset the processor using the Reset pin. Needless hours can be wasted searching for the cause of a malfunctioning Reset pin – I know that for a fact – so don’t overlook this potential cause for the problem.

Here are the pertinent paragraphs from the ATmega data sheet:

This post concerns the Open ARDF Equipment Project, which is utilizing the Receiver Development Platform, both of which are being developed together.

There has been a good deal of progress on the Dual-Band Receiver project this week, mostly on the software front.

This week I received an order from AdaFruit that included an FTDI Serial TTL-232 USB cable. That cable is, essentially, a USB-to-UART converter. Drivers for that cable are available for all the popular computer operating systems: Linux, OS X, Windows. Installation was a snap. I just plugged it into a USB port on and my computer, and it found and installed the appropriate drivers with no issues. My computer then showed a new serial port available: COM3 on Windows.

Only three wires from the FTDI cable needed to be connected to the Digital Interface Board: RX, TX, and ground. After wiring it up, installing a terminal emulator (PuTTY), and setting the baud rate to 9600 baud, the PC was able to “talk” to the Dual-Band Receiver’s Digital Interface Board. This opens a new universe of possibilities for the project.

PC Control

Using the serial interface provided by the FTDI cable, it is now possible to control the Dual-Band Receiver using the same Linkbus messages used for communication between the Digital Interface Board and the Control Head. So, from the PC, one can set the band, frequency, volume, monitor signal strength and battery level, etc. just like one does using a Control Head. The only difference being that you need to type in the correct Linkbus messages and then interpret the response messages from the receiver.

PC control could be made much more convenient by writing a PC application to provide a nice GUI interface for the user. One might have a graphical image of a receiver on the PC display, and by interacting with the image (turning dials, flipping switches, etc.) the PC application would apply those settings to the receiver over the Linkbus FTDI-cable interface. But just having some icons, buttons, or text boxes would make setting the receiver intuitive and effortless, with no need to memorize the Linkbus message protocol.

PC control, even without a GUI receiver application, means that it is no longer necessary to build a Control Head in order to test and experiment with the Dual-Band Receiver. This should make it much easier, and less costly, for anyone wanting to experiment with the receiver. The same capability will be added to the transmitter too.

Bootloader

The serial interface also provides the communication support required for bootloading. A bootloader is a small software program that resides in a special memory location in the microcontroller: a segment separate from the main program memory. The bootloader gets called immediately after the ATmega328P resets (or powers up), and before control is passed to the main program. The bootloader automatically checks the processor’s UART to see if a PC (running a special programming tool) is connected, and if one is present the bootloader supports writing new software into the ATmega328P, updating the main program.

A bootloader simplifies the process for updating the receiver software because updating can be done without the need for an “In-System Programmer” (ISP) device. Instead, all you need is the FTDI cable. Better yet, once the FTDI chip is added to the receiver design, you will only need a standard USB cable, such as the one that comes with most commercial electronic devices (cell phones, cameras, etc.) that connect to computers. We should also be able to utilize the DTR signal line coming out of the FTDI FT232RL chip, allowing the programmer to automatically trigger a reset just prior to programming the device.

Open source bootloader software is available on GitHub. Using the Optiboot source code, it was possible to create an Atmel Studio project that builds, installs, and debugs a simple bootloader for the Receiver Development Platform. A simple bootloader is working as of now, and has been used to successfully update the software on a Digital Interface board. This was accomplished running AVRDude on the PC: the same free software updater program many Arduino experimenters use.

Since we can now build and modify our own bootloader, we have total freedom in making it work the way we want. So we should be able to make it work conveniently for the user. Perhaps even making it possible for a future version of the Control Head to apply software updates to an attached receiver or transmitter.