-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LoRa Modulation Settings #14
Comments
Note on Code Rate: |
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. |
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. |
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. |
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:
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. |
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) |
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. |
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. 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? |
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. |
@sharph: Thanks for keeping the ball rolling. Your assessment looks spot on, though I'm confused by the statement @voteblake and @rrahmani: Thanks for providing great research and insight into the regulations. Huge help. Frequency Hopping Bandwidth vs. Time on Air 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: 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. |
@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. |
@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. |
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.
The text was updated successfully, but these errors were encountered: