Conversation
…d don't turn off Bluetooth if it's invalid)
…spacing in modem configuration functions.
…gion. Corrected some text. Inserted todo items.
Updated US ham mode to full legal frequency range Set hamfast to a legal setting
Update HAM US433 frequency range and config settings
Update protobufs and classes
|
As per comments in #8855 an that have been happening elsewhere, I'd like to further discussions on this somehow. Happy for someone to let me know what the best channel for that is. As I understand it, the general concerns are:
This addition is such an important one that it really needs as much community consultation as possible, either to determine the best path forward that works for the users, or simply to educate (myself included) them, as there's likely some misunderstanding surrounding all of this. Hoping that there can be some useful discussions surrounding this going forward :). |
|
I won't respond to all the comments and questions here and in #8855 and #7481, but I will explain as much as I can. I will preface this by saying I am not a subject matter expert, nor a legal professional. This PR is submitted as an independent contributor who lives in the former EU, and while it may be adopted by Meshtastic, I am not writing for or on behalf of the project. Firstly, I should say that there are the following concerns:
With specific regard to the EU868 band from 869.400-869.650MHz, I've been reading ETSI EN 300 220-2 V3.3.1 which, according to Annex A, is a harmonised standard to meet the requirements of 2014/53/EU (the Radio Equipment Directive). This is publicly available for everyone to read, and I thoroughly recommend everyone does so. Figure 6 in that shows how emissions in the out of band region are to be controlled, and shows that immediately outside of the operating channel there is a limit of 0dbm/1khz (noting that 0dbm = 1mW). I've interpreted this as a Spectral Density figure, but this is an assumption on my part. For a radio outputting 500mW (27dbm) across 250kHz, that equates to 2mW/khz. If the frequency drifts at all, then the radio will be non-compliant. By reducing the radio output by 3dbm (27 -> 24dbm), to 250mW, the output will be 1mW/khz, or 0dbm/khz. The out of band limit reduces by (250khz x 2)/36 ~= 1dbm every 14khz, so the radio needs to be even lower if the frequency drifts outside the domain. At 5% drift (12.5khz for 250khz BW), one would need to be at 23dbm output, and so on. From this it's possible to see that a 22dbm radio operating at BW = 250khz across the whole band is Probably OK. However, when we move to BW = 62.5khz, the spectral density is much higher - 8mW/khz for a 500mW radio. Luckily for us, the out of band domain applies outside of the operating channel, and the operating channel can be defined as a smaller section of the total permitted band, and you don't have to use it all. So by dividing the channel into 3x operating channels that are 83khz wide, and then using BW = 62.5khz, we give ourselves space to drift up and down before we go outside of the operating channel and have to start decreasing the output power. If we used a band that was directly adjacent to the lower or upper edge of the band, we would have to reduce the output power to 1mW/khz or 62.5mW output (i.e. 18dbm) even with an almost perfect TCXO, and would have to reduce it further to accommodate any kind of oscillator drift. tl;dr: We need padded operating channels to allow us to use the full power of the radios. If we operated closer to the edge of the permitted frequency band, we would need to lower the output power accordingly. |
Thanks so much for writing that @NomDeTom. Although tedious to write out, it's really helpful to understand the logic and reasoning for implmenenting things in certain ways. There's some great information there to digest, and I/perhaps others will do a bit of digging (in particular with the spectral density charactaristics of LoRa modulation) and see if we come to the same conclusions, but your reasoning seems sound enough based on what's written. Although there are many SRD devices on-band that, let's just say, aren't too strict with compliance, there's always the possibility to lead by example, especially with a project of this nature that now has become so popular. We don't want to make excuses for it being outlawed. At the same time, if there's a way to legally cater for a not insignificant user base already using particular settings, then it's worth exploring a little. |
|
@NomDeTom First of all thank you for you analysis and work.🙂 I must also say I'm not a lawyer or field expert either, but looking into the document IMHO Figure 6 (and Table 7) doesn't apply to the frequency band but rather the transmission band, in other words if you use 62.5kHz channel, your OCW, f and fnom would be the ones of that 62.5kHz channel indeed. In other words it applies to the side channel emissions resulting from the modulation. Although LoRa modulation doesn't have a rectangular spectral density and does have a drop at the edges (although I don't know how much), and if my understanding is correct part of certifying the European Conformity (CE mark) for EU868 is certifying it does comply with these regulations. If they didn't comply with the 4.4.6 section you brought up they would be illegal regardless of firmware settings unless operated at a low enough power. On the TCXO part, I'm pretty sure that the only 27dBm+ EU868 device that exist is the RA01SHP that some people use for DIY devices (which If I'm not mistaken, it doesn't have a CE mark) ,other than those all other both commercial , like Heltec V4, Station G2,TBeam 1W, etc, and the ones used in most 27dBm DIY devices like the Ebyte E22/E22P all have TCXO. That said it would be interesting to measure the devices with a Spectrum Analyzer to see what the real actual transmitted spectral density looks like😀 Other than that, I think it's important to take into consideration collisions with other LoRa devices, because using the orthogonality between Spreading Factors it can be completely avoided, also the 4 channel division, allows to use 62.5kHz and 125kHz channels simultaneously (although they would collide with the LoRaWAN RX2) while the 3 channel division you either use 62.5kHz or it collides with everything and if you transmit in the Channel 3, any other LoRa device in that part of the band with same BW but different center frequency would also collide😉, and that would be a lose-lose situation for both, and if you were to use same frequency but different SF they would both be orthogonal and be able to transmit at the same time (Like it would be if you use the current 62.5kHz 4 channel division and slot 4). Another benefit of using spacing between channels that also must be said, is that if you use the 4 channel divisions and you have Meshtastic nodes next to each other in side channels (For example one node in channel 2 and the other in channel 3 but otherwise same settings), they will hear each other and correctly decode each others packets, which even though is a bit of an edge case, we did try it as we are currently doing tests with 62.5kHz in Spain, and it works (although obviously with terrible SNR) 😂 IMHO if the EU868 RDEF stays as it is and a new 3 channel one is created (which if I understand correctly is the idea) this shouldn't be a problem and everyone could choose based on what's best for them, like @rob-fi in Finland for example.🙂 |
|
Thanks for the insight @derpyspike! But yes the collision with other LoRa devices is a concern because so many are generally operating in the middle of the band, so keeping well away from them is an important consideration. I believe that was the whole reason the EdgeFastLow "setting" came about. There could be a 3rd channel in the middle of course if spacing was really wished, but having 4 makes more sense. I just hope that this topic can remain open and with good discussion going forward to determine what is absoutely possible or not. It's my worry that this just gets barged through and merged without any further consideration, so I'll try to flag this for discussion as much as I can both here and in Discord, and I'll try to consult with some experts on the subject too. There's discussions brewing about a Meshtastic fork that would include such edge of frequency settings and that's the last thing I want to see happening. With regards to the meshtastic collision of adjacent channels, well, having devices next to each other is going to do that :D. That's unfortunately a general RF problem for more than just meshtastic! By the way here's an illustration of a 62.5kHz bandwidth meshtastic message with the marker set to 62.5kHz bandwith also. This a completely uncalibrated (other than the ppm offset of the receiver adjusted) measurement of a node a few meters away outside a window (in -15°C, clearly has TCXO), so the signal is very strong. But it serves to illustrate how the energy is concentrated within the bandwidth. 
|
Yup. I do a lot of this late at night, and it's hard to keep one greyscale picture separate from another. The details are subtly different - e.g. the rate of slope at the edges. 4.4.8.2 says that specific limits apply to the edges of the "Permitted Frequency Band" - which drop at 0.18dBm/khz in Figure 7, rather than those in Figure 6, which uses 2x OCW for the slope (giving 0.288dBm/khz for a 62.5khz OCW). Noting that this is a stricter requirement, I think it doesn't undermine the point - the stricter of the requirements will apply, unless stated otherwise.
Lora is specifically crafted so that each chirp sweeps the whole of the operating band equally.
This is a whole other patch of thorns. My brief understanding is that you're welcome to purchase components and put them together legally. Selling them as a complete device would require a certificate.
Lora-on-lora interference is minimal, unless the devices are on top of each other - it changes the noise floor, nothing more. Partial overlap with a source of interference is probably fine, too. I've been informed that Lora is better at recovering from random noise rather than a few scrambled bits in one place.
What you're describing is what we're trying to avoid - spurious emissions in the adjacent bands. It is literally what the document is instructing you to do.
Yup - you're all invdividuals, with your own thoughts and feelings and opinions. Noone should be telling you what you should or should not do, within the boundaries of the possible, the legal, the sensible and the safe. If one setting doesn't work, and another does, then use it. Meshtastic is all about communication, after all.
Collision with other Lora devices in the middle of the 869.525 is not the primary concern - as above, I am not concerned with lora-on-lora interference in the slightest, except from general good-actor perspectives. The principle concern is with other types of uses that dominate the central band - strong FSK signals and so on - from things like temporary traffic lights and other unidentified utility type transmissions that simply block us out. Having 4 bands would certainly be nice, but from my comments above, these are the regulations that we are trying to work inside. Out of band is measured at the edges of the operating channel. The nominal frequency is defined as the centre of the OCW. By adding some padding to the bands, we can ensure that the chances of interference are minimised and everyone will be happy.
As I've said before: if you can read the same text as me and tell me it doesn't apply, or my interpretation is incorrect then please do so. I am always happy to be corrected, have my understanding improved or simply shown the error in my process. To some degree, I wish we had just gone ahead with this in the first form. We've been discussing this for several months now, and I want to see progress as much as anyone. I think the idea of a fork simply to skip setting a few custom settings is interesting. If there is motivation to make and maintain such a fork, perhaps those individuals would instead consider looking at the other areas of improvement for the project? As you can see, the code for the change is progressing, and in a way that doesn't cause confusion and disruption to the wider userbase. There is an open issues list, and plenty of improvements to be made without duplicating the efforts of other teams.
Yes - this is something we specifically need to avoid. The absolute last thing I want is for an enforcement action to be served on well-meaning Meshtastic users, and this can be avoided by applying ourselves to the planning stage.
If you read the later sections of the ETSI EN document, it will tell you how the official tests are performed. Your picture fully illustrates the out-of-band emissions and the rectangular distribution of the radiated energy within the band. The limits are given in the standard - we must attempt to comply! |
|
@NomDeTom Thanks again for your answer, just a few quick notes🙂
What I meant with LoRa not having a rectangular spectral density is indeed what you can see in @rob-fi image, there's a very clear drop at the edges and not constant spectral density across the channel (there is even distribution everywhere except the edges), in fact just by the image I would say you see around a 6-7dB drop at the edge frequencies compared to the center frequency, where is it indeed evenly distributed like you say.
This is just a property of RF circuits, even if you had a theoretical perfect filter and no out of channel or out of band emissions, the receiver would still have the same problem, in fact if you look at the SX1262 you would see it has "88dB blocking immunity at 1MHz offset", so with good enough signal even at 1MHz offset the same problem would appear, this is a problem with electronics generally
But again, I think what you are doing is extremely important, as with compliance one must make sure to check every single box and this is something where Meshtastic can and should lead by example😇 |
|
Thanks again for that @NomDeTom and @derpyspike
What I'm most interested in is precisely what that drop is for LoRa. I don't know at this point does LoRa and the typical Semtech radios already have a specified fall-off at the edges in order to comply with such regulations? I'd really like to find that out but I haven't found the right documentation yet that goes into that detail. This is important not simply for steering the course of this issue, but rather knowing that do the existing Meshtastic presets comply, and does the continued use of both Meshtastic users of EFL and also does Meshcore comply, that does the same at the other end of the band. I have a suspicion that they might do BUT I do not know this, and I'd really like to find out.
I fully agree with this. However, what I will say is that it questionable about enforcing the limits for these specific presets if the existing presets also turn out to be in violation of the regulations, and there's no desire to immediately correct that. One could argue the current Meshtastic presets need reworked to comply with regulations if legal compliance is top priority and it turns out that they violate regulations. |
I have little to no technical knowledge to contribute here, but want to point out that what you're saying is that; because the old presets might not be compliant, no effort should be made to make new presents comply either. This is in general a pretty dangerous stance. |
I interpreted it as "if existing presets are in violation, there should be desire to correct them as well." |
The complete opposite :) I was saying that there should be an immediate desire to correct them also, as well as informing those using "EFL" and also Meshcore that they're breaching regulations, if it turns out to be the case. I'm only trying to establish with absolute certainty what's in compliance and what isn't. |
That is probably outside the scope of this PR. |
My view is what I stated in the first long comment - that the existing LongFast EU868 preset is probably ok, especially where a 22dbm radio is used. The "shoulders" of the spectrum mask imply that the fall-off is quite gentle for that bandwidth, and the lower spectral density of the wider BW is also in our favour. If there is a correction to be made, I would seek to do it separately than this change, and I would seek to make sure that this "new" activity is compliant first and foremost. I hope that existing EdgeFastLow Meshtastic setups would move to this setup ASAP, once released, simply because it will have different channel names, frequency ranges, etc., and new users would expect to be able to use a preloaded preset rather than a custom one. Re: other lora meshes: I have no immediate interest in copying exactly what anyone else is doing. Meshtastic has previously used The Things Network and LoraWAN as templates, but I think that can only take you so far. I also have no desire to tell anyone else how they should set themselves up to comply with the regulations. To reiterate: I am not a subject matter expert, and apparently I have no credibility ;-) @Jckf Precisely - One PR cannot carry all this responsibility! |
I'm afraid to obtain that level of certainty would require consulting a suitable professional. I am a professional - not for this - and I can tell you that it will not be simple, cheap or unambiguous that all radios and use-cases will be given a stamp of approval. Without crowd-funding a project to answer the question (which, to be 100% clear, I am not in favour of), the best we can do is be humble, be realistic, attempt to interpret the law as best we can, and be conscious of the fact that we may be asked to justify ourselves or change our operating methods. |
I don't entirely agree with that due to the fact that the whole reason this discussion occurred was because this PR was modified to change the location and spacing of the slots in the band, which put them at odds with existing user's settings as well as general band usage. It was modified on the premise that it would have been breaching regulations if implemented the previous way. However, if it turns out that it's not breaching regulations then there's an argument to discussing reverting back to as it was originally planned, which would be beneficial for existing users. I do understand everything you've been stating, and the resources you've linked to @NomDeTom, please don't think I'm discrediting you because it's not the case. You've given lengthy and helpful explanations and I have no reason to doubt what you've been saying. My only niggle right now is that's not including the context of LoRa modulation specifically, and I really would like to apply the characteristics of LoRa into the equation, because I'm suspicious that these considerations may have been included in the specification. Unfortunately I've not yet found a paper or information on that topic in the limited time I've had to dig into it, or had time to contact someone at a regulatory body about it. I may have an opportunity to discuss with someone next week. Yes these things can be expensive but sometimes with the right connections, things happen. I know you're keen to move this forward but I feel this needs to be paused for now to give a little more time to look into this. I can't force you to nor expect you to do that of course :). And for sure this PR isn't the place for these wider discussions so let's leave this here, and I'll continue to look into it at least for my own satisfaction. I didn't wade in to this discussion to just cause a fuss, I have only as good intentions as you do. Many thanks for your efforts both for the project and for addressing this topic. It's much appreciated. |
NomDeTom
force-pushed
the
New_presets
branch
from
be12df9 to
329b302
Compare
| float spacing; | ||
| float dutyCycle; // modified by getEffectiveDutyCycle | ||
| float spacing; // gaps between radio channels | ||
| float padding; // padding at each side of the "operating channel" |
There was a problem hiding this comment.
@caveman99 this is the method we're using to centralise the frequency slots within the allowed bands.
| bool audioPermitted; | ||
| bool freqSwitching; | ||
| bool wideLora; | ||
| bool licensedOnly; // Only allow in HAM mode |
There was a problem hiding this comment.
this is unused for now, but lays the ground work for the hambands
| bool wideLora; | ||
| bool licensedOnly; // Only allow in HAM mode | ||
| int8_t textThrottle; // text broadcast throttle - signed to allow future changes | ||
| int8_t positionThrottle; // position broadcast throttle - signed to allow future changes |
There was a problem hiding this comment.
this is used for the PositionModule.cpp changes - current check is just for non-zero.
| bool licensedOnly; // Only allow in HAM mode | ||
| int8_t textThrottle; // text broadcast throttle - signed to allow future changes | ||
| int8_t positionThrottle; // position broadcast throttle - signed to allow future changes | ||
| int8_t telemetryThrottle; // telemetry broadcast throttle - signed to allow future changes |
There was a problem hiding this comment.
This is used for all the other telemetry changes - current check is just for non-zero.
| // Some clients/UI components display bandwidth/spread_factor directly from config even in preset mode. | ||
| if (config.has_lora && config.lora.use_preset) { | ||
| RadioInterface::bootstrapLoRaConfigFromPreset(config.lora); | ||
| RadioInterface::validateModemConfig(config.lora); |
There was a problem hiding this comment.
this is a rewrite of @thebentern checks, but using the tools we developed for this PR.
10 participants
Some new presets for a wider range of operations in the EU. Ham bands are now removed, pending further discussion.
Relies on meshtastic/protobufs#824 for protobufs.
What has changed?
What is needed to integrate these changes more widely
Acknowledgements
This change has been supported extensively by @Stary2001, @phaseloop, and @caveman99. Their input cannot be understated.
🤝 Attestations
Pro-micro DIY