Information about fox controller software for arduino

March 09, 2015  G. D. (Joe) Young <jyoung@islandnet.com>

March 15, 2015 - add codppmx3 - see below
March 29, 2015 - add codppmx6 - see below
April 09, 2015 - add codppmx7 - see below
September 15, 2015 - add codppmx8, text2code - see below
Feb 17, 2016 - correct LED coming ON continuously in beacon mode
Feb 27, 2016 - codppmx8inv version with #ifdef choice of output polarities
Aug 30, 2016 - codppmx8US several changes to conform to US callsign ID

At this writing the minifox controller in codppm and codppmx are at 
'work-in-progress' level of development. Revisions will be posted here,
usually overwriting the earlier version.

The initial development was to make a plug-in replacement controller for
the VA7OM/VE7BFK minifox transmitter. The existing controller based on a
ATtiny13 with program originally from DF1FO is suitable for foxOring 
competition--that is, it runs continuously, and is intended to be deployed
in a largish area where adjacent transmitters cannot be heard simultaneously.
Continuous transmitting means that there is no critical timing.

For a sprint competition, the low-power transmitters must be timed to take
turns transmitting to avoid interfering with each other because they will be
located in a much smaller area. In particular, the timing is on a one minute
cycle where each of 5 transmitters has a 12 second time slot. Consequently,
the timing becomes a fairly stringent requirement. The codppm programs explore
methods for meeting this timing requirement.

The first program codppm (a crude contraction of code during pulse per minute,
or something like that), uses the internal oscillator of the ATtiny85/45/25,
divided down to produce a pulse-per-second output on PWM output A (pin 6).
It was observed that the period of this pps was not very precise or stable.
Also, that the adjustment opportunities available -- changing OSCCAl, or 
changing the divide-by count each amount to around 7 to 10 seconds per hour.

Experimenting then switched to using a crystal oscillator at 1MHz. The 
resulting period is very stable, but the available division ratios do not
give an exact 1 second. For example, 1000000/4096 = 244.140.. and dividing
that with an 8-bit pwm register value of 244 gives 1.000576.. Hz, or about
0.999424 second. This problem would go away if you could buy a 1.024 MHz
crystal. It seems that 1.8432 MHz is available, and that would allow an
exact 1 pps with division by 8192 and 225. That will be tried when I can
get my hands on those crystals.

Meanwhile codppmx (for codppm using crystal) has a period trimming dodge
where one slow period (final divide by 245) is inserted in to every 5th
'best' period (divide by 244) to correct the average time. This works well,
achieving timekeeping within a second over 8 hours. A similar adjustment
strategy MIGHT also work with the internal oscillator--also still to be 
tried.

March 15/15
-----------
codppmx3 is a 1.8432 MHz crystal controlled version as mentioned above. The
timing accuracy is very good--first trial found about 2 seconds in 24 hours.
There remain a couple of issues: the current drawn (at 3V) is about 50% more--
1.25 mA rather than .8 mA for the 1MHz crystal. Also, the arduino environment
used so far (version 1.0.5) does not seem to build with the new cpu frequency,
so the millis( ) timing is 1.8 times shorter. In turn, the code speed is a
bit fast. The timing could easily be corrected by multiplying the millis( )
timing values by 1.8. However, as the build environment is supposed to allow
specifying the cpu clock frequency, it's not changed in this version of 
codppmx3. It appears that the next version of the arduino ide now being rolled
out may correct this issue.

March 29/15
-----------
codppmx6 has modified the timer1 interrupt routine to use the 'normal mode' so
that the output from the pwm on pin 6 is free for other uses. The code sending
is modified to include 'O' -- ie, it now sends MOE, MOI, ... as required by
the IARU current sprint rules. The starting time for the code is indexed by the
fox number: every fox is started on the even minute, fox 1 begins immediately,
fox 2 begins 12 seconds later, fox 3 begins 24 seconds later, etc. The freed
pin 6 is used for the transmitter control, the led is left on pin 5, but the
LED now only comes on for the first 12 second transmission and thereafter is
off. Finally, the output pins for both the Tx and LED are modified for open-
drain operation. This mode is realized by writing 0 to the output buffers, then
changing the pinMode from input (Tx, LED OFF) to output (Tx, LED ON).


April 9/15
----------
codppmx7 uses the remaining pin 7 input as an analog input with 4 levels to
determine the mode of operation for the controller. The modes are: 0) sprint
1) fast sprint, 2) continuous and 3) 1min/4min timing. The development of this
controller software was originally to realize accurate timing of the transmit
intervals for the sprint competition, emerging as a standard feature of IARU
ARDF competitions. But given accurate timing, it was considered useful to be 
able to use the minifox for 'demonstration' purposes for a standard-timing 
foxhunt with on time of one minute, and off time of 4 minutes. As well, to
incorporate the fox-orienteering mode, a continuous transmission mode is 
needed, and the sprint competition calls for both a slow CW group of 5 Tx and
a fast CW group. To be able to select all 4 modes with the available single
pin, an analog/digital conversion is done and 4 levels are discriminated for
the mode selection. A separate software timer is used to stop the LED output
after 30 seconds for the continuous mode. The arduino environment seems unable
to set the cpu clock frequency to 1.8432 MHz as it should, so the dot duration
has been adjusted by a factor of 1.8432 to realize 10 wpm and 14 wpm speeds for
the sprint and fast sprint CW timing, respectively.


September 15/15
---------------
codppmx8 has the additional feature of identifying the transmissions with a
callsign trasmitted at a high speed to be short enough to fit in <12 seonds. 
To allow for changing the callsign without modifying the rest of the
controller code, the callsign is stored in the ATtiny85 eeprom. The fox ID is
also stored in the eeprom. The eeprom stores the fox and call in the form of
bytes encoded for Morse code. The bits of each byte represent dots (bit = 0)
and dashes (bit = 1), with a 'fence' 1 bit preceding (from the left) the start
of the code pattern. For example, the letter V is encoded as 000010001; the 
letter M as 00000111. An arduino utility text2code can be used to prepare the
eeprom data in intel-hex format, which can be used by the avrdude programmer
to load the eeprom. An example output screen from text2code:

enter text string - example: MOE de ve7bfk/7

4D 4F 45 20 44 45 20 56 45 37 42 46 4B 2F 37    input as ASCII hex
07 0F 02 00 0C 02 00 11 02 38 18 12 0D 32 38    input as code bytes
MOE DE VE7BFK/7   input line as encoded   char count = 15

intel-hex file format (with added 0xff terminator):
:10000000070F02000C020011023818120D3238FFDF
:00000001FF

The avrdude command to load this hex file (saved with editor as eee.hex):
  avrdude -c usbtiny -p attiny85 -U eeprom:w:/home/joe/Desktop/eee.hex:i


The controller program expects to find the ID information at location 0 of the
eeprom, the first 3 bytes being the repeated fox ID. The program examines the
3rd byte to determine the fox number. The remainder of the text is arbitrary--
the length can vary, and any text can be used as the callsign. The length of
the text following the MOx should be reasonably short because it otherwise 
would take up too much time to send in the sprint modes and would thus overlap
the time assigned to the next fox in sequence.

In all modes, the fox transmits the first MOx then the callsign is inserted
at a high Morse code speed, then for the remaining time left in the transmit
interval, the MOx continues. This callsign insertion only occurs once every 
30 minutes after the first transmission from power on. For the other normal
times the transmit interval is completely occupied with MOx.

In the continuous (beacon) mode the callsign is transmitted immediately 
following the first MO and then only once every 30 minutes after that.

It is also possible to completely suppress any callsign insertion by placing
the end-of-call byte, 0xff, at location 4 in the eeprom. 0xff is the 'not
programmed' state of the eeprom, so if only the first 3 bytes for the fox ID
are loaded into a new ATtiny85, then there will be no callsign insertion. If 
there has been a callsign setting previously, then bytes 3 and 4 should be set
to 0xff to suppress call insertion.

The controller program, the eeprom contents, and the fuse programming (for 
1.83432 MHz external crystal) can be accomplished with one avrdude command:

avrdude -c usbtiny -p attiny85 -U eeprom:w:/home/joe/Desktop/ee5.hex:i 
-U flash:w:/home/joe/Desktop/codppmx8.hex -U lfuse:w:0xeb:m

This command assumes the programmer in use is usbtiny, the processor is 
attiny85, the eeprom contents are in intel-hex file ee5.hex, the controller
flash program is in intel-hex file codppmx8.hex, and the lfuse value is 0xeb.
Each of the hex files is located in /home/joe/Desktop/


August 30, 2016
---------------
Several modifications required to conform to US callsign insertion requirements.
Namely, callsign at END of transmission, codespeed no higher than 20 wpm, ID
interval 10 minutes or less. Also added #ifdef selection of no-overlap timing
adjustment--where one Tx completes it's transmission BEFORE the end of its 
allotted ON time.

Program is called codppmx8US. See separate documentation package.





