The WISP transmit code is a bit convoluted. This page explains some of its inner workings.
In order to reduce power consumption, the transmit code is highly optimized. This allows a minimum of supply voltage and clock frequency to be used, which improves wireless range and duty cycle. The hardware timers provide an excellent opportunity to employ specialized hardware to perform the transmit waveform creation. Unfortunately, we need to modulate the timer in real time, and do so synchronously with the timer. This is accomplished by having the timer and the code run at the same rate. The timer is generating the output waveform, and the code is modifying the timer to create data modulation. The code consumes exactly N instructions
Clock rate: 3.072 MHz
BLF (Link Frequency): 256 kHz
Miller type: M4
Data Rate: 256 kHz / 4 = 64 kbps
Clock cycles per half bit period: 24
1. The uplink frequency for the WISP is 256 khz, Miller-4 encoded. Always. (unless you change it yourself).
2. When transmitting, the WISP is transmitting a square wave at some frequency. This is done by having the timer count up to some number, one tick per clock cycle, and then the polarity of the transmit signal is flipped. The counter is reset to 0 and the process starts over. (The timer does this automagically in UP / COMPARE mode)
3. The Miller encoding has two pulse lengths. One full cycle of a 256khz square wave is ~ 4 us long. So, the short pulses are ~2 us, and the long pulses are a full cycle so those are ~4 us. (If this doesn't make sense, look at the miller sequences in the Gen 2 spec while you read it.)
4. The SEND_CLOCK macro sets the system clock to ~3.0 MHz. This should probably get documented in the code. 6 MHz is stale documentation.
5. R15 is set to 5 cycles, which is 2 us given a 3.0 MHz clock (timer counts N+1 cycles). So, the timer counts off 6 cycles, 2 us, and then changes the polarity of the transmit cycle. This gives the 256 khz square wave.
6. Whenever it is time to transmit a long pulse, the pulse width of the square wave is changed to N+1 = 12 cycles (4 us). The assembly code very carefully counts off ONE pulse at this lower frequency, and then the pulse width is set back to 2 us.
7. The assembly code is just counting off cycles, and very precisely controlling how long the 256 khz square wave is sent, and when the occasional long pulse is sent.
In p 396 that "The number of timer counts in the period is TACCR0+1" while working in UP mode. That's why the timer counter values are 5 and 11 instead of 6 and 12.
PS: MSP430x2xx User's guide can be download from focus.ti.com/lit/ug/slau144e/slau144e.pdf
What do these registers mean?
R14 and R15 are the values that the timer interval are set to in order to create long or short pulse intervals.
Why do you think the system clock is ~2.5 MHz? The SEND_CLOCK macro sets DCO = 110 (=6) and RSEL = 1001 (=9), but I can't find exactly which frequency represents, in MSP430x2xx User's Guide. Looking at figure 5-5 (p 292), I can imagine that is over 1 MHz, but I don't know how to calculate it exactly from DCO and RSEL.
We have always just measured it with an oscilloscope.
TI has some sample code that uses the 32kHz oscillator to measure the DCO (and even set the DCO). You'll find it in their code examples.
Just change the DCO clock frequency. Everything in terms of timing will scale together. One thing to be careful of: the RX to TX delay (reader to tag) is in terms of the RX clock - not the TX clock.
The clock that drives the code has a separate prescale divider than the timer. If we slow down the code execution so it modifies the timer half as often, we get twice as many square waves between phase inversions. This is exactly how the Miller modulations work.
Note that the DCO frequency stays the same (as does the timer frequency), but the code runs slower. This keeps the BLF the same, but slows down the data rate by the Miller modulation factor.
The last modification was made by - yeagerd on Apr 26, 2012 9:28 am