Daniel Barlow
8ee10214c8
we use cqueues, which is the async framework that lua-http is built on. we integrate it into the glib event loop rather hackily by calling the cqueues event stepper ever 20ms from a glib timeout function overpass has very low rate limits so we handle a 429 response by sleeping for a random length of time and retrying. This is, also, a bit of a hack
157 lines
4.7 KiB
Plaintext
157 lines
4.7 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?
|
|
|
|
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
|
|
|
|
[done] a) we can get data from overpass api as json
|
|
|
|
[done badly] 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 do something smart but complicated like "only return ways that
|
|
cover more than 1/16th the length of the tile"
|
|
|
|
d) render ways according to their type (road/cycleway/path/etc)
|
|
|
|
e) label the ways
|
|
|
|
f) async tile fetching
|
|
|
|
we don't want everything to stop when it's time to fetch a new
|
|
row of tiles, what are our options? lua-http is built on cqueues
|
|
which is async enough to make my head hurt, but we also need
|
|
to make it coexist with the gtk event loop
|
|
|
|
assumptions:
|
|
1) gtk stuff has to happen in the main thread (whatever that is...)
|
|
so we can't control it from cqueues because that has its own
|
|
threading stuff
|
|
2) there will be lots of fds from lua-http, do we really want the
|
|
housekeeping of making GLib.io_add_watch for each of them? it looks
|
|
like adding a glib source from lgi is not currently practical
|
|
https://github.com/lgi-devs/lgi/issues/111
|
|
|
|
3) if we put http calls inside cq:wrap, that make them background
|
|
provided that we call (cq:step 0)
|
|
periodically. we could do that in a glib idle function, perhaps.
|
|
|
|
- The tile fetcher would need to know where to write the data when
|
|
eventually it comes back
|
|
- need some say to not fetch the same tile 18 times if there's more than
|
|
one request for it while a previous request is in progress
|
|
|
|
|
|
----
|
|
|
|
https://git.syndicate-lang.org/tonyg/squeak-phone/raw/commit/474960ddc665ed445a1f5afb0164fe39057720f9/devices/pine64-pinephone/modem-docs/80545ST10798A_LM940_QMI_Command_Reference_Guide_r3.pdf
|
|
|
|
----
|
|
|
|
|
|
|
|
|