얼마 전? 몇주 전부터 구글번역기에 인공신경망을 이용한 번역엔진이 적용되어 꽤 유연한 번역이 가능하다.
참고로 파파고가 PC에서 안되는게 흠이지만 모바일에서는 파파고가 최고!ㅋㅋ)
* Preamble
The preamble is used to synchronize receiver with the incoming data flow. By default the packet is configured with a 12 symbol long sequence. This is a programmable variable so the preamble length may be extended, for example in the interest of reducing to receiver duty cycle in receive intensive applications. However, the minimum length suffices for all communication. The transmitted preamble length may be changed by setting the register PreambleLength from 6 to 65535, yielding total preamble lengths of 6+4 to 65535+4 symbols, once the fixed overhead of the preamble data is considered. This permits the transmission of a near arbitrarily long preamble sequence.
The receiver undertakes a preamble detection process that periodically restarts. For this reason the preamble length should be configured identical to the transmitter preamble length. Where the preamble length is not known, or can vary, the maximum preamble length should be programmed on the receiver side.
뭐라뭐라 영어가 길다...
별거 없고 그냥 PreambleLength는 6~65535까지 설정 가능한데 전체 PreambleLength는 여기에 +4심볼 한 거란다.
줄친 부분이 중요한데,
수신기는 정기적으로 다시 시작하는 프리앰블 감지 프로세스를 수행하기 때문에 PreambleLength는 송수신기 모두 같아야 한다.
PreambleLength가 알려지지 않거나 변경 될 수있는 경우, 최대 프리앰블 길이는 수신 측에서 프로그래밍되어야한다.
이런 말이다.
* Header
Depending upon the chosen mode of operation two types of header are available. The header type is selected by the ImplicitHeaderModeOn bit found within the RegModemConfig1 register.
헤더... 2가지 모드가 있는데
RegModemConfig1레지스터에 있는 ImplicitHeaderModeOn비트로 설정 할 수 있단다.
* Explicit Header Mode
This is the default mode of operation. Here the header provides information on the payload, namely:
- The payload length in bytes.
- The forward error correction code rate
- The presence of an optional 16-bits CRC for the payload.
* 명시적헤더모드(기본)
- payload길이는 bytes단위이다.
- "정방향 오류 정정 부호율" 이라는데.. 그런가보다..
- payload에 대한 선택적(RxPayloadCrcOn등 으로 CRC을 사용할건지 선택 가능)16-bits CRC가 있다.
The header is transmitted with maximum error correction code (4/8). It also has its own CRC to allow the receiver to discard invalid headers.
헤더는 최대 오류 수정 코드 (4/8)로 전송됩니다. 또한 수신자가 유효하지 않은 헤더를 버릴 수 있도록 자체 CRC가 있습니다.
(4/8 이란건 뭔지 모르겠다... ECC알고리즘 관련된거 같은데..음...
8bit데이터 + 4bit ECC란 건가??)
* Implicit Header Mode
* 암시적헤더모드
In certain scenarios, where the payload, coding rate and CRC presence are fixed or known in advance, it may be advantageous to reduce transmission time by invoking implicit header mode. In this mode the header is removed from the packet. In this case the payload length, error coding rate and presence of the payload CRC must be manually configured on both sides of the radio link.
Note With SF = 6 selected, implicit header mode is the only mode of operation possible.
페이로드, 코딩 레이트 및 CRC 존재가 미리 결정되거나 알려진 특정 시나리오에서는 암시 적 헤더 모드를 호출하여 전송 시간을 줄이는 것이 유리할 수 있습니다. 이 모드에서는 헤더가 패킷에서 제거됩니다. 이 경우 페이로드 길이, 오류 코딩 속도 및 페이로드 CRC의 존재 여부는 라디오 링크의 양쪽에서 수동으로 구성해야합니다.
참고 SF = 6을 선택하면 암시 적 헤더 모드가 가능한 유일한 작동 모드입니다.
또 영어가 길다...
결론만 말하면 이건 그냥 기본 헤더 없이 사용자가 raw으로 데이터를 보내는 것이다.
CRC계산 그런거 안해서 더 빠르단다.
SF = 6을 선택하면 이 모드만 가능하단다.
* Low Data Rate Optimization
Given the potentially long duration of the packet at high spreading factors the option is given to improve the robustness of the transmission to variations in frequency over the duration of the packet transmission and reception.
The bit LowDataRateOptimize increases the robustness of the LoRa link at these low effective data rates.
Its use is mandated when the symbol duration exceeds 16ms.
Note that both the transmitter and the receiver must have the same setting for LowDataRateOptimize.
낮은 데이터 속도 최적화
높은 확산 인자에서 패킷의 잠재적으로 긴 지속 기간이 주어지면, 패킷 송신 및 수신 기간 동안의 주파수 변동에 대한 송신의 견고성을 향상시키는 옵션이 제공된다.
LowDataRateOptimize 비트는 이러한 낮은 유효 데이터 속도에서 LoRa 링크의 견고성을 높입니다.
심볼 지속 시간이 16ms를 초과하면 그 사용이 의무화됩니다.
송신기와 수신자 모두 LowDataRateOptimize에 대해 동일한 설정을 가져야합니다.
LowDataRateOptimize 설정이란게 있는데 (자세한건 읽어보면 되고)
심볼 지속 시간이 16ms이상이면 의무적으로 사용해야 한단다.
일단... 여러 수식이 있다
Rs:LoRa symbol rate, BW:Bandwidth(Hz), SF:Spreading Factor
- PL is the number of Payload bytes (1 to 255)
- SF is the spreading factor (6 to 12)
- IH=0 when the header is enabled, IH=1 when no header is present
- DE=1 when LowDataRateOptimize=1, DE=0 otherwise
- CR is the coding rate (1 corresponding to 4/5, 4 to 4/8)
* 주파수 호핑 (FHSS)
4.1.1.8. Frequency Hopping with LoRaTM
Frequency hopping spread spectrum (FHSS) is typically employed when the duration of a single packet could exceed regulatory requirements relating to the maximum permissible channel dwell time.
This is most notably the case in US operation where the 902 to 928 MHz ISM band which makes provision for frequency hopping operation.
To ease the implementation of FHSS systems the frequency hopping mode of the LoRaTM modem can be enabled by setting FreqHoppingPeriod to a non-zero value in register RegHopPeriod.
* Principle of Operation
The principle behind the FHSS scheme is that a portion of each LoRaTM packet is transmitted on each hopping channel from a look up table of frequencies managed by the host microcontroller. After a predetermined hopping period the transmitter and receiver change to the next channel in a predefined list of hopping frequencies to continue transmission and reception of the next portion of the packet. The time which the transmission will dwell in any given channel is determined by FreqHoppingPeriod which is an integer multiple of symbol periods:
The frequency hopping transmission and reception process starts at channel 0. The preamble and header are transmitted first on channel 0. At the beginning of each transmission the channel counter FhssPresentChannel (located in the register
RegHopChannel) is incremented and the interrupt signal FhssChangeChannel is generated. The new frequency must then be programmed within the hopping period to ensure it is taken into account for the next hop, the interrupt ChangeChannelFhss is then to be cleared by writing a logical ‘1’.
FHSS Reception always starts on channel 0.
The receiver waits for a valid preamble detection before starting the frequency hopping process as described above. Note that in the eventuality of header CRC corruption, the receiver will automatically request channel 0 and recommence the valid preamble detection process.
RegHopPeriod레지스터에서 FreqGoppingPeriod을 0이 아닌 값으로 설정하면 주파수 호핑이 작동한다.
프리앰블과 헤더는 항상 0번 채널을 통해 전달되고 그 이후 주파수 호핑을 한다.
HoppingPeriod = Ts * FreqHoppingPeriod
오늘은 여기까지..
다행이 SX1276이 꼭 LoRaWAN Protocol을 써야하는건 아닌가보다.
SX1276+STM32 을 이용해 IoT통신장치, SX1276+RaspberryPi 을 이용해 IPv6-LoRa Gateway을 만들 계획이다.
댓글