There are three different frequencies available for Meshtastic
in the Philippines, each with pros and cons:
433 - 434.7 MHz <10 mW erp
868 - 869.4 MHz <25 mW erp
915 - 918 MHz <250 mW EIRP, no external antennna allowed
Philippines may also use LORA_24 unrestricted at up to 10mW, or up to
250mW if there is no external antennna.
Frequency rules in the Philippines are determined by aggregating the
information in laws, following the circulars referenced in the
[National Radio Frequency Allocation Table (NRFAT)](https://ntc.gov.ph/wp-content/uploads/2022/frequencyallocations/NRFAT_Rev_2020.pdf)
and then circulars that amend the circulars referenced in the NRFAT.
A full description of the regulatory basis can be found in the github issue:
https://github.com/meshtastic/firmware/issues/4948#issuecomment-2394926135
For 433MHz and 868MHz we refer to the Low Power Equipment rules for
"Non-specific Short Range Devices, Telemetry, Telecommand, Alarms,
Data In General and Other Similar Applications.".
For 915MHz and Wireless Data Network Services indoor device rules.
A device approved by the NTC is required for any use of Meshtastic
in the Philippines.
fixes https://github.com/meshtastic/firmware/issues/4948
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Previously our debug message for screens blandly stated
"Module wants a UI Frame"
This patch replaces the word Module with the name of the Module
in need of a frame a frame, enhancing debugging ability.
GetTimeSinceMeshPacket was duplicated in PowerTelemetry and
EnvironmentalTelemetry, albeit one had a cooler name than the other.
As we add HealthTelemetry, to avoid creating a third instance of
this method, let's move it somewhere that makese sense.
Adds a new method GetTimeSinceMeshPacket to MeshService and updates
EnvironmentTelemetry and PowerTelemetry to use it.
* added up to 3 channels via userprefs
* added up to 3 channels via userprefs
* added up to 3 channels via userprefs
* trunk fmt
* Added USERPREFS for GPS MODE
In 2020, geeksville had a NRF52840-dk development board with a
busted oscilliator. Let's retire it from service :)
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
The lora-relay boards were important pathfinders for nrf52
support some years back. They are no longer commonly produced and
there are now many nrf52 options on the market. Retire these
boards and associated variant.
* Enabling Ve pin on T114
Problem:
The Ve pin was not enabled in the firmware, and it was supposed to control the power to the GPS via the GPS_EN pin. As a result, users were forced to rely on the 3.3V pin to power their additional peripherals, which caused a constant power draw from the battery, even when the node was in deep sleep mode.
Solution:
To resolve this, Todd_Hervert and I decided to remove the GPS power toggle after testing revealed that the GPS only consumes 1mA in soft sleep mode. This minimal power consumption allowed us to enable the Ve pin without causing significant battery drain. Additionally, we added a delay to the I2C initialization process, as the Ve pin requires a few milliseconds to stabilize, which could prevent some peripherals from booting up in time.
Result:
The GPS operates as usual, drawing only 1mA of power.
The keyboard and other peripherals attached to the Ve pin now power off correctly when the node is shut down.
The I2C check initiates without issues after the delay, allowing all peripherals to function smoothly.
* trunk format
---------
Co-authored-by: Tom Fifield <tom@tomfifield.net>
* * Adding the -Wcast-align compilation flag for
the rp2040.
* * Some rework to use a struct to access radio data
* Buffer will not be accessed by arithmetic pointer anymore
* * Remplace arithmetic pointer to avoid Warning
* * Avoid 2 little artitmetic pointer
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
