137 lines
3.9 KiB
Plaintext
137 lines
3.9 KiB
Plaintext
|
|
Config for my moto harpia to turn it into a bike computer. We will
|
|
need
|
|
|
|
- working gps
|
|
- bluetooth (ble) stuff
|
|
- wayland "cage" compositor
|
|
- an app
|
|
- rsync service so that trails can be downloaded to a computer
|
|
- ip connectivity with flight mode
|
|
- give it telent and dandroid as APs
|
|
- use rfkill aggressively to save battery
|
|
|
|
|
|
Absent any reason I should not write the app in fennel I'm going to
|
|
write the app in fennel. I want it to
|
|
|
|
- display speed/cadence/time of day/power
|
|
- show where I am on a map
|
|
- record trail of where I've been (note: indoor counts too)
|
|
|
|
|
|
|
|
can we somehow do non-flakey bluetooth (is it dbus?)
|
|
|
|
|
|
|
|
cool extras
|
|
===========
|
|
|
|
adjust screen brightness
|
|
|
|
* turn off backlight when stopped after a minute
|
|
* dim the screen when following a route and the next
|
|
navigation instruction is still some way off
|
|
* tap to wake screen
|
|
|
|
note that IPS LCD requires as much battery for dark pixels
|
|
as light ones, so we get no power saving by colouring only part
|
|
of the screen
|
|
|
|
|
|
------
|
|
|
|
random notes follow ...
|
|
|
|
|
|
|
|
https://git.syndicate-lang.org/tonyg/squeak-phone/raw/commit/474960ddc665ed445a1f5afb0164fe39057720f9/devices/pine64-pinephone/modem-docs/80545ST10798A_LM940_QMI_Command_Reference_Guide_r3.pdf
|
|
|
|
|
|
|
|
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
|
|
|
|
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?
|
|
|
|
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
|
|
|
|
3) alternatively we could use mapbox vector tiles, but tbh I'm
|
|
struggling to see now that helps. we don't have to transform from
|
|
lat/long but instead we have to parse a protobuf, how is that simpler?
|
|
|
|
|
|
|
|
|