search

travisgoodspeed / loraham

Ham radio protocols and Arduino examples for LoRa on 70cm.
Other
270 stars 28 forks source link

LoRa Modulation Settings #14

Open matt-knight opened 7 years ago

matt-knight commented 7 years ago

In its current form, loraham uses the default modulation settings defined by the Radiohead driver. This configuration may suboptimal given the project's implicit goals of long range ad hoc networking. @travisgoodspeed and I have chatted about assessing the current settings and making a change if prudent.

The LoRa modulation has several proverbial knobs that can be turned to trade between throughput and range. The key parameters, their available values, and effects are:

LoRaHAM's current settings are SF 8, BW 125kHz, CR 4/5, and Low Data Rate mode disabled. These are balanced settings that result in a medium range.

I'm happy to propose more suitable parameters. If this is of interest, let me lead by asking if there are any time on air or band usage restrictions for the 433 MHz HAM band you've targeted. This will help scope the rest of the discussion.

matt-knight commented 7 years ago

Note on Code Rate: The Code Rate option allows you to choose the strength of your Hamming FEC. (7,4) and (8,4) can correct a single bit error and thus buy you additional link budget, but (7,4) is the only one you should use in practice. (8,4) can detect a second error but can only correct one, thus doesn't get you any performance gains in practice since uncorrected errors are also caught by the CRC.

travisgoodspeed commented 7 years ago

We'll change the rate, but exactly once and never again. Please start a branch for settings that reasonably maximize range over throughput and we'll merge on a weekend when the whole Philly network can be swapped over at once.

sharph commented 7 years ago

The library we are using defines several presets that are easy to use. Otherwise you are required to set registers manually.

My thought is that we want to turn the dials as far as we can in favor of longer ranges as long as we're not running into collisions.

matt-knight commented 7 years ago

If you could please provide the following information I'll chew on the numbers and suggest a configuration.

I think that's all I'll need. I will post again if anything else comes up.

voteblake commented 7 years ago

Some initial research on @matt-knight's questions. Part 97 governs here in the US of A.

§97.305(c) states §97.307(f) paragraphs (6) and (8) apply to the whole 70cm band.

§97.307(f)(6) reads to me that while using a "specified digital code" (in this case ASCII) the "symbol rate must not exceed 56 kilobauds" and "authorized bandwidth is 100 kHz."

§97.307(f)(8) might give us more flexibility as as it allows a whole set of emissions designators defined as follows:

(H)aving designators with A, B, C, D, E, F, G, H, J or R as the first symbol; 1, 2, 7, 9 or X as the second symbol; and D or W as the third symbol

I believe the three character designator is the legacy form and I'm having trouble putting together exactly what those would mean. Hopefully someone else can lend an eye to the above regulations and also weigh in on the emissions designators.

EDIT: Manually plugging some of the allowed emissions designators in to FCCID.IO suggest to me that none of them will modify the bandwidth limits from §97.307(f)(6) - so I think 100kHz it is.

rrahmani commented 7 years ago

Given the overall congestion on the 70cm band we should probably err on the side of being good neighbors and keep the transmissions as narrow as feasible

Phone is 25kHz for most ham applications (12.5 or 6.75 kHz for the digital voice modes)

ghost commented 7 years ago

Chirp modulation is a type of spread spectrum, so in that case, there is no bandwidth limit. The narrowband mode limits do not apply. In fact, you probably want about 20 MHz with Direct Sequence. You can also combine Frequency Hopping with that. Since LoRa is chirp, BW limits are on the chip, not in the regulations. The only limit is interference to others, so long chirps are probably problematic.

sharph commented 7 years ago

I've opened PR #16 with all the dials turned all the way towards range (with the exception of bandwidth, for which I think there is still discussion to be had, and code rate, for which @matt-knight suggested (7,4).) Nothing set in stone; I just wanted to generate some discussion and to have some code we can easily plug numbers into.

I think frequency hopping is a cool idea, but I'm worried the implementation will be tedious and not yield very much benefit. Frequency hopping with these radios requires the radio to interrupt the MCU every so often to ask it for a new frequency to tune to. I think that the library we're using will get in our way. We should consider it if there is a simple and most importantly stable way to implement.

LoRa Modem Designer's Guide

According to the guide, the chip rate is equal to the bandwidth (125kHz = 125kchips/sec.) Narrower bandwidth = more range, lower throughput/longer time on air. If we're going by the examples and equation given in the guide, it appears to be 3dB for every halving/doubling of bandwidth. Depending on if we want to exist in a traditional data channel or if we want to be spread spectrum we might want to push BW to be narrower or wider. If we go narrower, we might want to adjust our spreading factor to account for the time spent on air.

Maybe let's go as narrow as we can, though. Adjusting bandwidth to double the transmission time appears to be 0.5dB better than adjusting spreading factor to double transmission time.

@matt-knight Does this seem right and do you have further suggestions? I don't believe we have any time-on-air restrictions; at least not at the time scale where meshing is possible.

@voteblake @rrahmani @ObjectToolworks, & others who might be more part 97 minded: What should we do? Go narrow? 62.5kHz (the setting under 125kHz?) 7.8kHz?

rrahmani commented 7 years ago

Giving the SS designator, our operation is covered under part 97.311, and that gives us a lot of leeway as long as we don't interfere with non SS operations. The only aspect I'm not entirely sure of is what the IDing requirement is... previously it was explicitly stated in 97.119, but it was revised out.

matt-knight commented 7 years ago

@sharph: Thanks for keeping the ball rolling. Your assessment looks spot on, though I'm confused by the statement we want to exist in a traditional data channel or if we want to be spread spectrum. Do we have input, or is LoRa spread spectrum by definition?

@voteblake and @rrahmani: Thanks for providing great research and insight into the regulations. Huge help.

Frequency Hopping From conversations with @travisgoodspeed about the goals of the project, I believe frequency hopping is out of scope. Jump in and correct me if I'm wrong.

Bandwidth vs. Time on Air Going narrow will improve range but will have a serious detrimental effect on time on air, which in turn will reduce maximum throughput and affect the longevity of battery powered nodes. Additionally if channel congestion within the LoRaHAM network is of concern, a narrowband modulation will exacerbate it.

The attached plot illustrates the tradeoffs between bandwidth and time on air. These values are for a hypothetical 53-byte length packet (taken from the README: KC3BVL KK4VCZ Hey Jim, it's Travis. Care for a beer?) Each line represents a spreading factor, code rate is 4/7.

lora_toa

At 7800 Hz BW, the fastest/lowest sensitivity modulation of SF 7 has a TOA of approximately 2.13 seconds, and that time goes up as SF (and thus sensitivity do)... so it's slow. Maybe that's OK though; I don't have a sense of how chatty LoRaHAM is now or how busy you expect it to become. For reference: 144 dB and .242s TOA under the current modulation (BW125000/SF8/CR45), 153.3 dB and 2.13s TOA with the aforementioned hypothetical scheme (BW7800/SF7/CR47).

If Time on Air is less of a consideration, then perhaps a narrower bandwidth and low spreading factor is the way to go: for instance, BW10400/SF8/CR47. If congestion or battery life is a concern then we can relax the bandwidth and find a compromise. It's probably a good idea to turn on low data rate mode, although I'm struggling to identify to what extent it affects the link budget.

sharph commented 7 years ago

@matt-knight I'm a bit unsure of whether we have input myself. LoRa is clearly chirp-based spread spectrum, but since you can configure it at such low bandwidths it starts to look like a digital modulation that could occupy the same amount of spectrum of modes the FCC would classify as "data" in Part 97.

chrismerck commented 7 years ago

@matt-knight Regarding bandwidth, keep in mind many users have low-cost crystals (HopeRF modules) which may fail to communicate at minimum bandwidth due to frequency error. I'm unsure of the distribution of this error, but 125kHz+ should be safe considering these modules are intended to at least work for LoRaWAN.

Also, in light of the 70cm band plan, it would be most appropriate to operate LoRaHAM between 420 and 430MHz, which is for experimental and wideband modes like television. Ideally 426MHz.

I do understand that 434MHz is convenient as there are many antennas designed to operate here, but at this frequency we may experience interference in both senses with remote controls under FCC 15.231, and amateur repeater interlinks.

http://www.arrl.org/band-plan

dc2mw commented 7 years ago

I did some tests with low-cost modules using crystals last year. lora_crystal_test

Datasheet tells us that a bandwidth of 62 kHz would be some "magical border" that mandates use of TCXOs. Problems occured mainly in combination with high spreading factors. These very long on-air-times (e. g. 20 seconds for some bytes) would not be useful anyway. You can always go two or three steps back (SF or BW or both) from that non-working configuration.

Generally narrow (=less than 125k) bandwidth is possible with crystals. Further investigation would be needed to get an idea how much margin for extreme temperatures is left.

Reducing BW from 125k to 30k gives about +6dB sensitivity as the noise will drop inside the channel. Rule of thumb: 6 dB increase in link budget gives twice the range. We are experimenters, aren't we ;-)