commit 43ec3b436eeadad142b2b9354c035158789aebd2
parent cfb9c2ce79a16bbfba14c56d35dab02aa8ba7d00
Author: Daniel Barlow <dan@telent.net>
Date: Fri, 27 Feb 2026 15:18:55 +0000
add mess to readme from btwiuse
Diffstat:
| M | README | | | 71 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- |
1 file changed, 68 insertions(+), 3 deletions(-)
diff --git a/README b/README
@@ -60,17 +60,82 @@ maybe we could put the polylines in app-state. if we store
random notes follow ...
+1) [done] connect Satellite to qmi-nmea
+https://codeberg.org/tpikonen/satellite/src/branch/main/satellite/nmeasource.py#L106
+
+2) [nope] do we need modemmanager? might be required if we want lte data,
+but that's up to the "site admin" - we don't need it for biscuit itself
https://git.syndicate-lang.org/tonyg/squeak-phone/raw/commit/474960ddc665ed445a1f5afb0164fe39057720f9/devices/pine64-pinephone/modem-docs/80545ST10798A_LM940_QMI_Command_Reference_Guide_r3.pdf
+3) we should make saturn give visual feedback while it's loading an
+app. How does it know when the app has finished loading? Maybe it
+could get told when its window is obscured
-----
+4) rename Maps to soemthing that describes its role better. Cockpit?
+HUD? (but it's actually H Down D) Head Unit? Navigate? Dashboard? Cluster?
+Codriver? Satnav? Binnacle? Launch? Ride? Embark?
-https://git.syndicate-lang.org/tonyg/squeak-phone/raw/commit/474960ddc665ed445a1f5afb0164fe39057720f9/devices/pine64-pinephone/modem-docs/80545ST10798A_LM940_QMI_Command_Reference_Guide_r3.pdf
+5) [all done]
+Maps also needs to open the nmea port and parse data from it.
+5a) Maps needs to open a fake nmea source for testing
+5b) we need a generator of fake nmea data
+
+6) Cockpit
+- show [done] speed and [done] direction
+- show speed limit
+- [done] scroll and [not done] rotate map
+- overlay planned route on map
+- show next turn
+- voice prompts
+- when off-course, calculate route to nearest point on course
+- fetch planned route from nominated url
+(don't want to type the url in, is there a better way to have it check in
+with a mothership?)
+- save trail (maybe this could be a separate task entirely)
+
+elapsed time: what should it actually show? moving time, I guess
+- moving time since when?
+
+should we rename bearing as course in nmea?
+
+rotating the map is going to be complicated because the widget we're
+using doesn't support it (bitmapped map tiles)
+
+
+
+perhaps we need a server-side component for route planning
+
+
+7) think about how to use nfc tags or something for profiles so that
+it can recognise when it's attached to bicycle or motorbike
+
+
+8) use OSM directly?
+
+we can't rotate the map using OsmGpsMap widget because the labels will
+be sideways or upside down, so we need something with vectors that we
+can rotate
+
+a) we can get data from overpass api as json
+
+b) we would like to cache the results, which means some kind of
+chunking or tiling so that the json for position a is the same as the
+json for position b.
-----
+c) at coarser zoom levels, we need to query for fewer objects: either
+do it by hand -
+- houses
+- minor roads
+- major roads
+or so something smart but complicated like "only return ways that
+cover more than 1/16th the length of the tile"
+d) I think we will need some kind of server so that multiple users get
+the benefit of the caching. If we're going to do that, should it also
+do transformation e.g. from lat/long to x/y co-ordinates? We don't
+need this bit yet though
