Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


Mode1 (ISO 18000-7) physical layer description

Modern transceiver ICs need a preamble of alternating 1's and 0's to bring in the bit-synchronizer in the receiver onto the correct bit rate. Preamble bit-rate must be same as message bit-rate. Mode1 specifies a 30μs preamble vs. 36μs data rate.
When these transceivers are receiving the idle channel noise, they are searching for preamble. Preamble is used by receiver to synchronize its own data sampling time to that of the remote transmitter. This is commonly known as CDR or Clock recovery. The synchronization method implemented in silicon will not function if preamble rate is different than data rate.
Some transceiver ICs have a method to bypass this synchronization method, where baseband data is asynchronous, without corresponding clock. With SX12xx transceiver devices, this is accomplished in “continuous” mode with bit-synchronizer off. Data can be handled by host microcontroller using timer peripheral, yet dependance on low PLL jitter (phase noise) is increased.
Because of this, Mode1 should only be considered for supporting legacy applications. All new designs should use Mode2, so transceivers can be used as they were intended.

Mode1 on STM32L

STM32 devices have timer input capture with DMA channels, which make demodulating Mode1 signals possible under such adverse design misfortunes. Timer output compare can be used to generate transmitted data, with DMA used in circular mode in both RF receive (input capture), and RF transmit (output compare). DMA controller in circular generates interrupts when DMA is half done, and full (2nd half) done. This provides precise timing that is not heavily dependent on CPU execution speed or interrupt service latency.
For RF transmit, timer output compare pin is configured in toggle mode (TIM_OCMode = TIM_OCMode_Toggle), generating signal to directly modulate DATA pin on radio.
for RF receive, timer input capture is configured for input edge sensitivity of both edges (TIM_ICPolarity = TIM_ICPolarity_BothEdge), which directly decodes DATA pin on radio in RX mode. The primary downside being the need of CPU to service half and full DMA interrupts while searching for preamble from the background noise (MCU power consumption).
An artifact of both-edge input capture decoding is that its agnostic to data polarity, since all information is contained in Manchester timing (time between edges). On the transmitter side, this means extra attention is needed for data polarity adherence to standard.
In both transmit and receive, the same timer can be used with same DMA buffer, and same DMA channel. (this is half-duplex operation)
Using this reception architecture, another timer is needed to handle the case of low-level unmodulated carrier on the radio frequency. In this case, input-capture interrupts may cease due to lack of background noise. When a valid radio message is received, this extra timer will start to ensure the message is completely processed in the event that DMA interrupts have ceased.
While the primary purpose is to support Mode1 modulation, Mode2 modulation may also be supported simultaneously at the physical layer, which could be advantageous to aid in migration from the old deprecated standard, to the current standard.

Mode1 on CC430

CC430 has potentional for Mode1 operation by using Asynchronous Serial Operation, enabled by setting PKTCTRL0.PKT_FORMAT to 3. Timer_A is then used as baseband (de)modulator.
However, the DMA controller in MSP430 appears to only have an interrupt for transfer complete. DMA half-transfer interrupt is required for practical operation.
Asynchronous operation of radio with MSP430 would only be recommended if circular DMA is possible with separate half and full transfer interrupt flags.

Mode1 CRC

Some assumptions must be made on Mode1 CRC (reference Code Fragment 5):

  • CRC is calculated least-significant bit first, same order as bits transmitted over air. Using CCITT/V.41 reverse polynomial 0x8408
  • stop-bits are not included in CRC calculation
  • leading zero bits will not be checked due to initial CRC value of 0x0000

In the most general sense, CRC implementation must be considered from the perspective of a mathematician. Order of Transmitted CRC bits are considered as highest-order coefficients, and lowest-order. This ultimately dictates the bit-order of CRC compared to bit-order of message.
Different interpretations of these choices can lead to incompatible (non-standard) implementations.

opentag/radios/mode1.txt · Last modified: 2012/03/07 20:39 by dudmuck