Further to https://github.com/meshtastic/firmware/pull/7772 ,
we discovered that some RTCs have hard-coded start times well in the
past.
This patch gives RTCs the same treatment as GPS - if the time is
earlier than BUILD_EPOCH, we don't use it.
Fixes#7771Fixes#7750
Further to https://github.com/meshtastic/firmware/pull/7772 ,
we discovered that some RTCs have hard-coded start times well in the
past.
This patch gives RTCs the same treatment as GPS - if the time is
earlier than BUILD_EPOCH, we don't use it.
Fixes#7771Fixes#7750
* Merge pull request #7777 from meshtastic/create-pull-request/bump-version
Bump release version
* Only send Neighbours if we have some to send. (#7493)
* Only send Neighbours if we have some to send.
The original intent of NeighborInfo was that when a NeighbourInfo
was sent all of the nodes that saw it would reply with NeighbourInfo.
So, NeighbourInfo was sent even if there were no hop-zero nodes in
the NodeDB.
Since 2023, when this was implemented, our understanding of running city-wide
meshes has improved substantially. We have taken steps to reduce the impact
of NeighborInfo over LoRa.
This change aligns with those ideas: we will now only send NeighborInfo
if we have some neighbors to contribute.
The impact of this change is that a node must first see another directly
connected node in another packet type before NeighborInfo is sent. This means
that a node with no neighbors is no longer able to trigger other nodes
to broadcast NeighborInfo. It will, however, receive the regular periodic
broadcast of NeighborInfo, and will be able to send NeighborInfo if it
has at least 1 neighbor.
* Include all the things
* AvOid memleak
* We don't gotTime if time is 2019. (#7772)
There are certain GPS chips that have a hard-coded time in firmware
that they will return before lock. We set our own hard-coded time,
BUILD_EPOCH, that should be newer and use the comparison to not set
a bad time.
In https://github.com/meshtastic/firmware/pull/7261 we introduced
the RTCSetResult and improved it in https://github.com/meshtastic/firmware/pull/7375 .
However, the original try-fix left logic in GPS.cpp that could
still result in broadcasting the bad time.
Further, as part of our fix we cleared the GPS buffer if we didn't
get a good time. The mesh was hurting at the time, so this was a reasonable
approach. However, given time tends to come in when we're trying to get
early lock, this had the potential side effect of throwing away valuable
information to get position lock.
This change reverses the clearBuffer and changes the logic so if time
is not set it will not be broadcast.
Fixes https://github.com/meshtastic/firmware/issues/7771
Fixes https://github.com/meshtastic/firmware/issues/7750
---------
Co-authored-by: Tom Fifield <tom@tomfifield.net>
* Add On-Screen Keyboard for UpDownInterrupt. Pls notice the new keyboard layout was inspired and adviced by https://github.com/csrutil
* Add longPress event for RotaryEncoder Press.
* Update UpdownInterrupt UP and DOWN on main UI.
* Change the interrupt trigger mode from rising edge to falling edge to improve button response.
There are certain GPS chips that have a hard-coded time in firmware
that they will return before lock. We set our own hard-coded time,
BUILD_EPOCH, that should be newer and use the comparison to not set
a bad time.
In https://github.com/meshtastic/firmware/pull/7261 we introduced
the RTCSetResult and improved it in https://github.com/meshtastic/firmware/pull/7375 .
However, the original try-fix left logic in GPS.cpp that could
still result in broadcasting the bad time.
Further, as part of our fix we cleared the GPS buffer if we didn't
get a good time. The mesh was hurting at the time, so this was a reasonable
approach. However, given time tends to come in when we're trying to get
early lock, this had the potential side effect of throwing away valuable
information to get position lock.
This change reverses the clearBuffer and changes the logic so if time
is not set it will not be broadcast.
Fixes https://github.com/meshtastic/firmware/issues/7771
Fixes https://github.com/meshtastic/firmware/issues/7750
There are certain GPS chips that have a hard-coded time in firmware
that they will return before lock. We set our own hard-coded time,
BUILD_EPOCH, that should be newer and use the comparison to not set
a bad time.
In https://github.com/meshtastic/firmware/pull/7261 we introduced
the RTCSetResult and improved it in https://github.com/meshtastic/firmware/pull/7375 .
However, the original try-fix left logic in GPS.cpp that could
still result in broadcasting the bad time.
Further, as part of our fix we cleared the GPS buffer if we didn't
get a good time. The mesh was hurting at the time, so this was a reasonable
approach. However, given time tends to come in when we're trying to get
early lock, this had the potential side effect of throwing away valuable
information to get position lock.
This change reverses the clearBuffer and changes the logic so if time
is not set it will not be broadcast.
Fixes https://github.com/meshtastic/firmware/issues/7771
Fixes https://github.com/meshtastic/firmware/issues/7750
* Only send Neighbours if we have some to send.
The original intent of NeighborInfo was that when a NeighbourInfo
was sent all of the nodes that saw it would reply with NeighbourInfo.
So, NeighbourInfo was sent even if there were no hop-zero nodes in
the NodeDB.
Since 2023, when this was implemented, our understanding of running city-wide
meshes has improved substantially. We have taken steps to reduce the impact
of NeighborInfo over LoRa.
This change aligns with those ideas: we will now only send NeighborInfo
if we have some neighbors to contribute.
The impact of this change is that a node must first see another directly
connected node in another packet type before NeighborInfo is sent. This means
that a node with no neighbors is no longer able to trigger other nodes
to broadcast NeighborInfo. It will, however, receive the regular periodic
broadcast of NeighborInfo, and will be able to send NeighborInfo if it
has at least 1 neighbor.
* Include all the things
* AvOid memleak
* Rename System Frame (from Memory) in code base
* Create menu options to Show/Hide frames: Node Lists, Bearings, Position, LoRa, Clock and Favorites frames
* Move Region Picker into submenu
* Tweak wording for Send Position vs Node Info if the device has GPS
* Add BaseUI support for L1 EInk
* Fix Eink offset
* Add joystick
* Updates
* Adjust Seeed Wio Tracker L1 E-Ink variant (#7326)
* Rename variant
Needs the -inkhud suffix to work correctly with the web flasher
* Display driver for ZJY122250_0213BAAMFGN
* Remove dead code from nicheGraphics.h
Remnants of T-Echo's nicheGraphics.h file, which was used as a template.
* Use ZJY122250_0213BAAMFGN driver
Improves display health. We don't need as many full refreshes now.
* Tidying
* board_check = true
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
* Consolidation
* Add hack for existing InkHUD button functionality
---------
Co-authored-by: todd-herbert <herbert.todd@gmail.com>
We are currently blocked from making the breaking change to fix
EU_433 channel centres until 3.0 (https://github.com/meshtastic/firmware/issues/3371 )
However, as already updated in https://github.com/meshtastic/meshtastic/pull/919
the documentation, the power limit for EU_433 is 10dBm. We can change
the power limit without breaking anything, so this patch sets the
power limit to match the ETSI spec without changing any other settings.
