SRS Home | Front Page | Monthly Issue | Index

Search WWW Search seattlerobotics.org

First Steps: Telemetry, Using a Radio Modem

Doug Leppard (DLeppard@CCCI.Org )
Benjamin Leppard (Benjamin@Leppard.Com)

Author’s note:

This is the eight  in a series of articles outlining the steps I have taken to build my robot. These articles are focused on a robot that may compete in the Fire Fighting contest, be able to roam around the house, but mostly be a fun learning tool. The 68HC912B32 is the processor, so these articles will be on interfacing to the B32 various mechanical devices and sensors using SBasic as the programming language.

"Motorola’s S-Record" looking at the S-Record format that Motorola uses to load data and programs.

"Booting up the 68HC912B32 for the first time" described in detail how to boot the B32 up and run a program.

"State of the Union" gives an overview of what state the robot was in August 1999.

"Multiplexing Five Sonar Modules" goes into how to and the reasons of putting five Polaroid sonar transducers and wiring them together.

"Drivers for Sonar & Mapping" shows the software to drive the sonar units, and how it can map a room when tied to a PC.

"Using B32's Interrupts IRQ and XIRQ" using the B32 interrupts to count the robots wheel encoders.

Why telemetry

Early on I knew there must be a way to communicate to the robot while it was in operation.  The number one reason for telemetry is for testing and debugging.   As the robot is doing its thing and it is in error, you need to have data what it is happening in its program.  I can't imagine trying to debug the robot's program without having some idea what is happening with its program.  Secondly, you may want to allow the robot to communicate to the world.  For instance, in one of my previous articles, (Drivers for Sonar & Mapping), the HC12 transmitted back to the PC its sonar readings.  The PC then drew a map of the room.  Also, I can give commands to the robot via the PC and modem

As a side benefit, it made the downloading of the robot's program much easier.   Before the radio modem, each time I wanted to load a new program I had to hook up a serial cable to the MCU, which by design was located in the second layer of the robot and hard to get to.  But, using the radio modem I was able to load the data without having to hookup the serial cable to the robot.  In fact the only connection I need to make to the robot is the programming voltage needed to program flash memory.

By far the most important use of the radio modem is for testing.  When I was making the Fire Fighting program, I would put debug statements in the program.  I would make a run and collect on the PC the debug data.  It was invaluable in knowing what went wrong and what corrections to make.  Programming in Sbasic, all I needed for debug statements was simple print statements.

Ming transmitters and receivers

Early on in my robot plans I knew I needed to have telemetry on the robot.  I knew it would be absolutely necessary for testing and just for being a cool thing to have.  But, it was months before the robot got off the bench, so it was never important because the serial cable was always connected.  But once the robot got off the bench I saw I had to have something.  A Nuts and Volts article talked of the Ming transmitters and receivers.  I bought two pair to transmit and receive both directions.  I soon realized that I needed the transmitters working on different frequencies if the data was going to be passed both ways.

So I hooked up one pair of Ming TX99 and RE99 to transmit data back to the PC.   It worked pretty good at 1200 baud (1.2kb).  But that was slow in getting across the data  wanted.  Also the data would often drop out.  I found I could run at 4800 baud and get the data at closer the speed I wanted, but that was still slow for the amount of data I wanted to transmit and the drop out rate was even greater at the higher speed.

The Ming transmitters and receivers are fine for small applications at slower speeds and short distances.  See www.rentron.com for Ming and other remote control devices.

But I wanted rock solid data transmitted at higher speeds.  So I stated looking for other solutions.

InfoWave Modems

Last summer on the SRS list server, Karl Lunt mentioned he got a pair of radio modems from Innomedia.  The specifications sounded good, and if it was good enough for Karl it was good enough for me.  I happened to be in San Jose at the time and picked up a pair from Frys for about $150 (on sale at Frys, and as far as know they no longer have them).

The modems were designed to remotely connect a printer or two computers.   My unit had one serial and one parallel port.  It came with Windows software to run the base station.  It operates with 900mhz spread spectrum transmitters receivers.

I was so excited to bring them home to HC12 and hook them up.  The first thing I discovered was that the modems worked with Windows software and I couldn't use it with the software, I wanted to use, some of which was DOS based.  I contacted the manufacturer Innomedia and ended up talking with Adam the tech.  He was extremely helpful and said he had heard many people have used these modems for robotics.

Infowave Modem Specs

Note this was taken from Innomedia's web page on this modem. See www.innomedia.com/wireless/products/infowave_specs.html for complete details.  I have an older version of this modem but they are basically the same.  Below also talks about the 2.4 Ghz version, which I am not sure are available here in the USA.

InfoWave is a direct-sequence spread-spectrum data modem. It can be customized to operate in 902-928 MHz or 2.4-2.4835 GHz at data rates of 85, 96, or 250 kbps. An 85 kbps version of InfoWave has been certified by FCC and Industry Canada for unlicensed operations in the ISM frequency (902-928 MHz) band.

Features

• 902-928 MHz or 2.4-2.4835 GHz ISM Bands
• Digital direct-sequence spread-spectrum technology
• Serial port (RS-232) for easy host interface
• Point-to-point or point-to-multipoint applications
• Simple command set for fast system integration
• Air data rate at 85, 96, or 250 Kbps
• Auto-scan to select clearest channel
• Auto-channel change in the presence of interference
• Programmable PN code
• HDLC-like data link protocol for error control and flow control
• Adjustable packet size for optimum throughput

I tested the modem's distance by writing a program that sent data to the PC that I could watch for errors on the screen.  While the robot sat on the floor of my two story house, I walked until the modem gave up.  I was over 200 feet away, it had to transmit through several walls of the house, with the bottom floor of the house being made up of concrete blocks.

Never once did the modem send bad data, it would slow then get through and send chunks of data.  When I moved out of range it lost its connection and stopped.  So what I have seen is that the modem does not send bad data even when on the fringe of connection, it has a buffer built in and will catch up if possible when it has a better connection.

I did not test the open air abilities of the modem.

It's dimensions without the case are 3 7/8 inches wide, 4 3/4 inches long (with antenna sticking out 5 1/2) and 5/8 inches deep.

Setting up the modem to work with your robot, software

I have step by step instructions on how to set up the modem to be used with your PC and robot.  They are all contained in the document "Infowave setup instructions.pdf".  Go to Egroups.com and the group SeattleRobotics and look in the Files section under InfoWave Modem to see if there are any updates of these files.  The helpful files are:

There are three types of modems described above.  I use the 9208 version (or at least an older versions of that).   Adam Huffman of Innomedia has been very helpful in working out how these modems work.  Below is his description of each of the modems:

I will not go into detail here on hooking the robots to the modem software wise, for the document, Infowave setup instructions.pdf, handles that.  But some following points will be helpful:

• I did not use the software that comes with the modem , it is all Windows based and you loose direct control over the modems.
• The modems can be controlled directly by the robot and PC using its WM commands, which are like the Hayes modem controls.
• The modems default baud rate can be set.   It will also detect a new baud rate once booted and in command mode by detecting the speed the WM command was sent at.
• Usually you will use the modems to connect the robot to PC.  But you can change your modem to talking to another modem.  So if you had multiple robotics, robot 1 could be talking to robot 2 and robot 3 could be talking to robot 4.  Then robot 3 could disconnect and talk to another robot like 5.  But there is no broadcast so it would be only one robot to one robot (or PC) at a time.
• The modems seem rock solid, the only real problem I ran into was that once turned on they had about a 2 second boot period and if data was sent to them during the period they would hang.

This is the modem connected to my notebook computer.  The modem is powered off the notebook using the keyboard connector that has a 5 volt supply on it. It makes the whole operation portable.

You can see the modem mounted on the robot.  I have taken off the plastic case to save room. There are four switches to the left of the modem.   Switch 1 controls  the MCU to tell if it is to program the flash or to run a program.  Switch 2 controls if the MCU and associated electronics runs off the onboard power supply or the external supply.  Switch 3 controls the the power going to the modem, whether it is supplied by the onboard battery or external voltage.  Switch 4 keeps signals from getting to the modem until it is ready for them.

Hooking the modem up hardware

Hooking the modem to the PC was a piece of cake.  Just plug in the cable and make sure your program had the right com port.  I just changed notebook computer which I do most of my robotics on.  It has no serial port and I have a Xercom USB to serial converter and that works great.

Hooking to the robot is slightly more complicated.  The document  "Infowave setup instructions.pdf" goes into that with some detail.  Biggest thing is you get a short course in RS232 (serial) line definitions.  My recommendation is to wire your modem to your robot in the DCE mode.  Only difference between DTE and DCE is the transmit and receive lines are switched.  See the detail in the modem documentation for how it should be wired.

As you can see in this picture to the left, I just got a male serial connector  to connect to the modem and ran wires to the appropriate places on the robot.  Note, I did have the RXD line go through a switch so I could keep signals going to the modem until it went through its boot process to solve its problem of getting data before it was ready.  Again this is because of a flaw in the modem because if it gets signals before it is ready it hangs. See the table in "Infowave setup instructions.pdf" for wire connections. For power I just got the appropriate size power connector from Radio Shack. Most of the time I have the antenna laying down so that it will not block the rear sonar.   I have modem mounted on the board so I can see the lights and it seems better protected that way.

Using the modem with Sbasic

I use the Sbasic print and outch commands to output data to the modem that goes to the PC.  The same way I did when the I had a cable hooked up.  I use the inkey() command to get data from the modem.  It is great because I can send commands to the robot via my remote PC which made it more fun and testing was so much easier.  When testing a routine like PID where you had to adjust variables, I would run the routine have it stop, from my PC type in changes in the variables and have it run the routine again.  All without reprogramming the robot and only changing the variables found in RAM.

Steps in setting up the program to use the modem:

'--------------- following code run in initialization routines ----------

'Set up the port speed

    poke sc0bdh, 13    'sets port speed, 13 for 38400 26 for 19200 baud, 52 for 9600, 417 for 1200
    pokeb sc0cr2,$0c        ' Enable transceiver

'above is in my Rinit.lib file that runs first as part of the robot boot up

'--------------  this is code found in Rmodem.lib and is called by main program-----------------------------------
'rmodem
'routine for setting up modem

connect_modem:        'connect modem with ws1 command and wait until OK (sent by modem itself)
                        'note this must be in the text mode, if not run the
                        'wmen command to reprogram into text mode.  See WM command document for details.

    temp_lib6=0    'temporary variable to say what phase we are in

    do
        'note modem_status uses temp_lib6
        if usr(modem_status)=1    'wait until modem ready, does this by checking DTR/DSR
            wait_lib=intcnt     'check if it is still on 100ms later since once it is
                                    'turned on it has a pulse on for a short time
            do loop until usr(compare_intcnt,wait_lib)>100    'this is a delay subroutine that waits 100ms
            if usr(modem_status)=1     'wait until modem ready
                temp_lib6=1
            endif
        endif
    loop until temp_lib6=1

    temp_lib6=0
    do
        if temp_lib6=0
            gosub modem_command     'phase is 0 give it the WMS1 command to connect to other modem
            wait_lib=intcnt
            temp_lib6=1
        endif
        ch=inkey()             'now we will look for the OK
        if ch<>0
            wait_lib=intcnt         'as long as there is input, keep looking
            ch = ch AND $ff
            select temp_lib6
            case 1
                if ch='O'            'O of the OK found move to find K
                    temp_lib6=2
                endif
            endcase
            case 2
                if ch='K'            'K of the OK is found then ready, else any other letter reset to phase 1 to look for O
                    temp_lib6=3
                    else
                    temp_lib6=1
                endif
            endcase
            endselect
        endif
        if usr(compare_intcnt,wait_lib)>800     'try again if taking too long
            temp_lib6=0
        endif
    loop until temp_lib6=3        'phase 3 must have found OK
return

modem_status:    'usr(modem_status) returns 1 if ready 0 if not ready
    if peekb(portdlc) and %01000000>0
        temp_lib6=1
    else
        temp_lib6=0
    endif
return temp_lib6

modem_command:
    outch 'w'        'wms1 connects to base of radio modem
    outch 'm'
    outch  's'
    outch '1'
    outch 13
    outch lf             'not needed, only makes it look cleaner when testing
return

'--------------- end of Rmodem.lib --------------------------

Using the software in a program:

    gosub initialize    'run the initialization portion
    gosub connect_modem  'run the connection routine

    print
    print "hello world"    'all ready to communicate,this is sent via the modem to the PC

Buying the modem

Problem with this modem is that this technology is no longer needed for the public sector.  Serial ports are falling to USB.   Therefore Innomedia USA has stopped offering the modem and has no USA supplier.   In contacting Innomedia I have found that they are offering the modems through their Taiwan office.

I had hoped by the time of the publishing of this article I could have worked out a deal.  Steve from Acroname has been working with Innomedia to see if they can carry the modems.  But he was not able to work out the deal with them before the time the article needed to go to print.  Steve was doubting that there was enough margin for a business to carry the modems without buying a huge number of the modems.

I will post to the SRS list what we eventually find out on the buy.  Also look to the Egroups.com file area under the file BuyModem.txt for current information.