[breaking] fix EU433 LoRa definitions - #2696
Conversation
|
marking as draft since changing the start frequency will likely break backwards compatibility. other regions using 433.0f should also be reviewed. |
|
I am not sure this is necccessary, at least i recall similar discussions a while ago. Seems like ETSI specifies center frequencies with a bit of guard to allow for the bandwidth. The matching ITU allocations start and end at the band boundaries and Meshtastic takes that into account when calculating the center frequencies. Let's follow this up on #frequency-bands in discord. |
andrekir
changed the title
|
no rush, leaving as a reminder for the next breaking cycle. considering convention and even EU_868, it's pretty safe to say 433,050 MHz to 434,790 MHz is the proper frequency range for EU_433. |
|
Good eye @andrekir ! |
|
10 dBm ERP is 12.15 dBm EIRP, which form of radiated power are we using? If we assume a 0 dBi antenna, it should be the latter. |
|
Q) How about offering EU_433_OLD and EU_433_NEW in parallel for a while? That way communities could choose to move independently of our firmware timing? |
|
on second look, the added 50 KHz represents about 0.0115% in frequency shift, which I suspect is well within tolerance for radios to interoperate using either center frequency. I don’t have any 433 MHz radios to test that theory, though. |
Right now we have 433.0-434.0 which is 1 MHz or 4 default channels. New definition is 433.050-434.790 which is 1.74 MHz being (almost) 7 default channels. I propose to change it to 433.0-434.8 with a margin of error ... :-) - the 50khz spacing is really a guard against the next band user below and the gauss tx distribution is weaker near the edge of the band. Also we're talking a few milliwatts here, it's not like this is the Chinese Firedragon Shortwave jammer ... |
5c1bf81 to
b8dc114
Compare
I like this idea if it means we can have a corrected preset sooner. Eventually we can deprecate the EU_433_OLD after some time :) |
When EU_433 was originally defined in firmware, the band definition was off by a small amount. EU_433 is now in widespread use, so changing that definition is a breaking change. This patch introduces an alternative. In order to facilitate communities making a planned transition between the frequency bands at a coordinated time, this patch introduces EU_433_V2 . Selecting EU_433_V2 will configure a Meshtastic device with the corrected band definitions. The overall plan for the transition would look something like this: 1. Introduce EU_433_V2 to protobufs, firmware, and apps 2. Announce that communities have the option of making a transition to the corrected band, and encourage communities to coordinate a transition at a time that works for them. 3. After many months, we reach a time where the supermajority of affected communities have made a transition to the new band 4. We change app behaviour, making EU_433_V2 as the prominent choice over EU_433 5. We monitor complaints about band options and communities with a lagging transition. 6. We remove the original EU_433 from the apps See also: meshtastic/firmware#2696
|
If we add the part of 434,04-434,79MHz to the new version, I would advise that at least the default frequency slot does not fall within there. This part can be used without duty cycle with 10mW when using a narrow bandwidth (25kHz), hence it could lead to severe interference from other systems. |
|
@andrekir Hi - Can we please rebase this PR and make it ready for review? It seems this old PR is blocking the following similar work: Ideally, IN_433 should be a separate entity or perhaps an alias to this new EU_433 region. CC @caveman99 An old PR from 2023 (!) should NOT stop us from making progress on a new region (namely Thank you for the help. |
8 participants
EN300220 ETSI V3.2.1 [Table B.1, Item H, p. 21]