RayDialer

RayDialer (light [aka.: "reduced", not "bright" {although it is kind of "bright"}])
An optical, local positioning system for robot applications (infrared TX beacons and real-time directional RX photo-receivers).

Features:

  • multiple, distinguishable IR beacons
  • (almost) real-time receiving circuit
  • 4 channel directional receiving pattern
  • beacon messages (pro version)
  • external beacon communications interface (pro version)
  • measuring distance to single beacon (pro version)
  • "easy" (...) to build (reduced version)

This minimal positioning system consists of three parts:

  • TX: transmitting beacons
  • RX: directional receiving circuit
  • MX: omni-directional motor mount (radar; pro version, not presented here)


Hardware TX

The TX part of RayDialer, at least like presented here, consists of 3-12 IR LEDs, emitting base band amplitude modulated light. The modulation can chosen to be:
  • a) pure analog sine waves (standard)
  • b) digital (on/off)
  • c) digital PWM
  • d) single or multi frequency
  • e) ...

Right from the start, RayDialer was planned to emit more than only one frequency component. This reduces detrimental effects from other, interfering light sources and adds a little more confidence to the received and analyzed signal.

Creating a single (aka.: fundamental) frequency would be fairly easy. The circuits on the right, driven by an "amplified" or "boosted" MCU pin, or anything else, satisfy this demand. At least, regarding the sending unit.

To reduce some of the higher frequency components, a simple RC filter can be fed in for a 20dB/dec suppression. I don't want to bother you with any math or formulas, so here are some prepared and easy to understand visualizations:


Imod ~ Uf1 ('single digital')
FFT
Imod ~ Uf1 ('single, filtered digital')
FFT
At a glance, the preceding two sets of measurements may look ugly, but a digital (DFT/FFT, Goertzel, ...) analysis isn't really a problem, as long as:
  • the sampling frequency is high enough to avoid aliasing (also see sampling theorem)
  • the receiver bandwidth is limited (aliasing)
  • all beacons operate inside the frequency band:
    f_lowest < f < 2*f_lowest (below 1st overtone)
  • no external sources interfere
  • ...

What happens if we add a second frequency, "digitally mixed" to the first one?

Imod ~ Uf1 | Uf2 ('digitally ORed')
FFT
Imod ~ Uf1 + Uf2 ('digitally added')
FFT
Without going into detail (math) or commenting the slight differences between the two preceding rows, it is clear to see that the pure digital combination of two (or even more) adjacent frequencies results in a mess...

Although an analysis isn't problematic, even for signals like this, the signal to noise ratio (we simply treat the unwanted intermodulation and overtone components as "noise") will decrease with every further beacon added.
Additionally, the overall signal integrity "requires" (aka.: "better results") that no frequency is a multiple of another one and the difference between any of them is unique to all others.
And at least, slamming out a digital broadband signal, simply doing nothing else but blocking five times the bandwidth of the required signal, well - no ;)

Though there are ways and methods to improve the quality of the digitally generated signal (e.g. a narrow bandpass of higher order), a simple, cheap and wide spread solution is in use since ~1960:
Our telephone's DTMF dialing mechanism.

Now, you may guess where the name "RayDialer" results from ;-)

Imod ~ Uf1 + Uf2 ('pure analog')
FFT
The advantageous spectrum of two (or even more) combined sine waves can not be overlooked. The few drawbacks are a higher current consumption, compared to a short pulse-paused ratio of a digital system and a little more complex circuit (offset shifted current source including a regulation).

There are a lot of ready to use DTMF chips available. I decided to use a HT9200. It can be operated in parallel or serial input mode. Parallel mode only requires four pull-up or -down resistors to select one of the 16 different DTMF tone combinations. Additionally, a chip enable pin can turn the output on or off.
In its serial mode, the HT9200 can be hooked up to a microcontroller.


       Complete DTMF Frequency Table
     =================================
 
           1209Hz 1336Hz 1477Hz 1633Hz
     697Hz    1      2      3      A
     770Hz    4      5      6      B
     852Hz    7      8      9      C
     941Hz    *      0      #      D


Because the light intensity of an LED is (almost) direct proportional to the current, flowing through it, we need a voltage to current "converter".
The circuit on the right represents the absolute minimum, achieving this requirement.

The signal output of the HT9200 contains a DC offset of about 1/2*Vcc. The overlaying AC "audio" (shall I say optical, here? ;-) signal itself, is about 1Vpp (no load; see screenshot lower left).
A closer view reveals the discrete steps of the internal D/A converter (screenshot mid, right), they will be filtered out be the RC combination R2, C1 (fc=3.4kHz, can be lowered).

Despite the non-linear behaviour of the transistor Q1, the current flow through LED1 will be proportional to the voltage output of the HT9200. A coarse approximation (DC only):

Iled = (Udtmf - Ube) / R1
<=> Iled = (2.5V -0.65V) / 82Ohm
<=> Iled = 23mA

HT9200 signal output; Vcc=5V
a closer view...
just another one

The preceding, minimal circuit has many flaws:

  • the DC voltage offset causes a constant current offset and is not independent from the AC part
  • Q1 will cause unwanted intermodulations and does not provide a regulation
  • only one LED (even it is a high-power type) can not illuminate 360° (except for additional optics)
  • depending on the amount of LEDs, +Ub has to be chosen carefully (power dissipation Q1)
  • ...
But it may help getting quick "lab table results".


The full featured, all-inclusive test layout, which indeed contains much more stuff than a reduced-version-transmitter needs for operation, allows two basic LED orientations. As shown on the image at the right, the LEDs can be mounted horizontally, for direct receiver contact, or vertically, for indirect illumination of, e.g., a table tennis ball (or comparable ;-).

Each of the LEDs can be bypassed with a jumper. This comes in handy if the beacon is positioned in a corner or close to a wall. The circuit will automatically adjust the internal operating voltage to match the amount of LEDs and keep the losses low.

Reduced versions can of course be operated with a single IR power LED, without the need for a switching regulator or all the other fancy stuff...


Note: For latest version, see download section at the bottom...

all-inclusive schematic...
... and test layout
the real TX hardware

         RayDialer TX Channel Settings
   ===========================================
   Note: Switch pulls low, if ON.
 
   DIGIT    4   3   2   1     frequencies [Hz]
         
     1      ON  ON  ON  OFF      697 + 1209
     2      ON  ON  OFF ON       697 + 1336
     3      ON  ON  OFF OFF      697 + 1477
     4      ON  OFF ON  ON       770 + 1209
     5      ON  OFF ON  OFF      770 + 1336
     6      ON  OFF OFF ON       770 + 1477
     7      ON  OFF OFF OFF      852 + 1209
     8      OFF ON  ON  ON       852 + 1336
     9      OFF ON  ON  OFF      852 + 1477
     0      OFF ON  OFF ON       941 + 1336
     *      OFF ON  OFF OFF      941 + 1209
     #      OFF OFF ON  ON       941 + 1477
     A      OFF OFF ON  OFF      697 + 1633
     B      OFF OFF OFF ON       770 + 1633
     C      OFF OFF OFF OFF      852 + 1633
     D      ON  ON  ON  ON       941 + 1633



Hardware RX

RX1, The Beginning

RX1 detects the direction of one or more sender(s) by rotating up to four photodiodes and measuring the signal intensity at different angles. Thanks to a tiny, but powerful dsPIC, all channels are sampled simultaneously and analyzed by a real-time Goertzel-Algorithm.

The photodiodes used, have a 50% intensity angle of +-20°. Each of them is mounted with an angular offset of 40° to the adjacent one. Theoretically, this results in a constant, summed up signal level across rotation.
In practice, it requires bending, twisting and slapping ("fiddling around with photodiode position") the diodes until they are where they belong.

The differential signal input of two (or more) adjacent diodes is not used for position detection, only for a quick, first "guess" across an angular span of 160°. For operation, only one diode would be required, but four speed up things dramatically...

RX1 schematic...
... and test layout

The circuit consists of four equal detection circuits (CH1-4).
A standard photo detector circuit (aka "I-U converter"), formed by one half of the MCP602 (R1, D1) directly feeds the A/D input of the dsPIC.

Because only a single supply is available, R2, R5 and C4 provide an 1.65V offset for the circuit. The output signal, including the offset, is filtered by R4 and C5 (arithmetic mean, time constant ~10s (a little large, I agree ;-)) and fed back to the negative input of the photodiode amplifier via the second half of the MCP.
This way, any (speak: most of the) DC offset, caused by ambient light, will be corrected to 1/2 of the supply voltage.

The dsPIC provides a serial (115k, 8N1), as well as an I2C interface. For NXT compatibility, choose R23 and R24 to 82k. For real world I2C interfaces, reduce them to ~2k2-10k.

The processor had some spare pins left, so a tiny LCD was added to the test layout. It has to be mounted via IC-sockets or stuff like this.

to be continued... (11/2010)



noisy signal; 5kSps; 0.2s; float

clean signal; 5kSps; 0.2s; integer

real HW/FW sweep; 5kSps; 0.2s; 1Vpp input

like above, enlarged

like above, enlarged

like above, enlarged
The Scilab scripts, whose produced the simulations and the dsPIC captured frequency sweep, can be downloaded here. They may provide a good start understanding (and fiddling around with) the Goertzel algorithm.

Firmware RX

RX1

to be documented... (11/2010)


DTMF mode display

sweep display

5 bytes left; mission accomplished ;-)

    HOTKEYS (via serial, 115200,8N1):
    =================================		

     ESC  stop (after current operation)

      d   DTMF mode, all channels (4), all frequencies (8)
      D   DTMF mode, single shot
      s   sweep mode
      S   sweep mode, single shot

      a   sweep output for all channels (only serial)
      0   sweep output for one channel only
			
      c   sweep channel selection (one channel); requires IDLE_STATE; followed by:
        1    select channel 1
        2    select channel 2
        3    select channel 3
        4    select channel 4
        ESC  aborts channel selection

      f   sweep frequency range selection; requires IDLE_STATE; followed by:
        1    select tone 1;   sweep f1-47Hz..f1+48Hz
        2    select tone 2;   sweep f2-47Hz..f2+48Hz
       ...
        8    select tone 8;   sweep f8-47Hz..f8+48Hz
        a    select tone 1..8 sweep f1-47Hz..f8+48Hz
        ESC  aborts range selection

      r   reset max marker (horizontal bar resolution) for LCD value normalization

      l   linear intensity axis on LCD
      L   logarithmic intensity axis on LCD
      
      1    250 steps per Goertzel analysis
      2    500 steps
      3   1000 steps
      4   1250 steps
      5   1500 steps
      6   1750 steps
      7   2000 steps
      8   2250 steps
      9   2500 steps
			
      ?   show help message
      h   show help message


Number of Goertzel steps (samples) and effects.
Download this Scilab script here, or use SiSeLi ;-)

Notice that the output values are NOT NORMALIZED (divided by the number of samples)!
Use the source ;-)


    OUTPUT FORMAT IN DTMF MODE:
    =============================
		
      <channel>,<f1>,<f2>,...<f8>

      START_DTMF
      1,1982,1559,974,14,284,2,96,518
      2,1985,1508,978,19,289,2,103,511
      3,1774,1487,281,473,788,377,557,117
      4,1793,1433,291,468,718,370,552,110
      STOP_DTMF


    OUTPUT FORMAT IN SWEEP MODE (ALL CHANNELS):
    ===========================================
    
      <channel>, <frequency>, <intensity>
      
      START_SWEEP
      1,650,2221
      1,651,2149
      1,652,1356
      1,653,347
      1,654,10
      1,655,614
      1,656,1583
      1,657,2030
      2,650,2103
      2,651,2046
      2,652,1284
      2,653,319
      2,654,24
      2,655,667
      2,656,1650
      2,657,2062
      3,650,1926
      3,651,1501
      3,652,483
      3,653,0
      ...
      1,1002,10
      1,1003,614
      1,1004,1583
      ...
      4,1703,1501
      4,1704,483
      4,1705,4353
      STOP_SWEEP


    OUTPUT FORMAT IN SWEEP MODE (ONE CHANNEL):
    ==========================================
    
      <channel>, <frequency>, <intensity>

      START_SWEEP
      1,650,2131
      1,651,2093
      1,652,1332
      1,653,315
      1,654,21
      1,655,658
      1,656,1633
      1,657,2084
      1,658,1640
      ...
      1,1704,1344
      1,1705,112
      STOP_SWEEP


    Firmware channels
    ==================
		
      CH   f[Hz]
			
       1    697
       2    770
       3    852
       4    941
       5   1209
       6   1336
       7   1477
       8   1633

Useless Pics



minimal TX (pure analog)

minimal RX
totally saturating the receiver;
still working ;)
Well, not quite exactly...
The S817 isn't really that large ;-)
the real TX hardware
the real RX1 hardware
...
TX mounted on a battery pack
do NOT attach a 9V battery ;-)

Download

RayDialer:

Includes:
- schematic (PDF)
- placement (PDF)
- layout, Eagle (BRD)
DOWNLOAD: RayDialer-TX_hard_V12.zip V1.2; all-inclusive version

DOWNLOAD: RayDialer-RX1_hard_V12.zip V1.2 HW; 12/2010
DOWNLOAD: RayDialer-RX1_firm_V10.zip V1.0 FW; 11/2010
DOWNLOAD: RayDialer-RX1_source_V10.zip V1.0 FW; 11/2010
DOWNLOAD: RayDialer-RX1_scilab-ana_V06.zip V0.6 Scilab Sweep Analyzer; 11/2010




ASkr 06/2010 initial version
ASkr 09/2010 found some time to add RX1 HW
ASkr 11/2010 added the missing HW TX V1.2; added FW RX1 V0.5; added HW RX1 V1.1
ASkr 12/2010 changed HW to V1.2
ASkr 11/2011 added firmware source V1.0