Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .github/workflows/docs-linkcheck.yml
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,10 @@
name: Docs Link Check

on:
pull_request:
paths:
- .github/workflows/docs-linkcheck.yml
- docs/

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a bad idea, urls accessibility can be flaky, causing noisy CI, better do it offline and periodically fix

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your call, but this will still only run if a particular PR touches on of the docs files, so it wouldn't cause most of the PRs to even run. I guess some of your recent work has touched the folder though https://github.com/coredevices/PebbleOS/commits/main/docs

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can still be noisy (from my experience in other projects). Just checking: will this check all links?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's just the ones inside the docs folder, but I think that might glob in the CONTRIBUTING.md at the root too.

schedule:
- cron: "0 6 * * 1"
workflow_dispatch:
Expand Down
2 changes: 1 addition & 1 deletion docs/architecture/activity/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ The logic used to pull out and identify the stepping signal from the spectral de

VMC, or Vector Magnitude Counts, is a measure of the overall amount of movement in the watch over time. When the watch is perfectly still, the VMC will be 0 and greater amounts of movement result in higher VMC numbers. Running, for example results in a higher VMC than walking.

The VMC computation in Pebble Health was developed in conjunction with the Stanford Wearables lab and has been calibrated to match the VMC numbers produced by the [Actigraph](http://www.actigraphcorp.com/product-category/activity-monitors/) wrist-worn device. The Actigraph is commonly used today for medical research studies. The Stanford Wearables lab will be publishing the VMC computation used in the Pebble Health algorithm and this transparency of the algorithm will enable the Pebble to be used for medical research studies as well.
The VMC computation in Pebble Health was developed in conjunction with the Stanford Wearables lab and has been calibrated to match the VMC numbers produced by the [Actigraph](https://ametris.com/actigraph-leap) wrist-worn device. The Actigraph is commonly used today for medical research studies. The Stanford Wearables lab will be publishing the VMC computation used in the Pebble Health algorithm and this transparency of the algorithm will enable the Pebble to be used for medical research studies as well.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's better to drop the link, but from the redirect to the new domain, this seemed closest to what was described


VMC is computed using the formula below. Before the accelerometer readings are incorporated into this computation however, each axis’ signal is run through a bandpass filter with a design of 0.25Hz to 1.75Hz.

Expand Down
1 change: 1 addition & 0 deletions docs/conf.py
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,7 @@
# Sites that are alive but block automated requests
linkcheck_ignore = [
r"https?://reveng\.sourceforge\.net/.*",
r"https://https://www\.itu\.int/rec/T-REC-X\.25-199610-I/en",
]

# -- Options for myst_parser extension -----------------------------------------
Expand Down
2 changes: 1 addition & 1 deletion docs/reference/pulse2/flash-imaging.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ high-latency links.
maintain a minimal, fixed-size amount of state.

> The idempotence of writing to flash is leveraged in the design of this
> protocol to effectively implement a [Selective Repeat ARQ](http://en.wikipedia.org/wiki/Selective_Repeat_ARQ)
> protocol to effectively implement a [Selective Repeat ARQ](https://en.wikipedia.org/wiki/Selective_Repeat_ARQ)
> with an unlimited window size without requiring the server to keep
> track of which frames are missing. Any Write Data command to the same
> location in flash can be repeated any number of times with no ill
Expand Down
24 changes: 12 additions & 12 deletions docs/reference/pulse2/pulse2.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ retransmissions into the application protocols in an ad-hoc manner,
poorly. This has made the design and implementation of prompt and file
transfer protocols more complex than necessary, and no attempt has yet
been made to tunnel Pebble Protocol over PULSE. It's the [waterbed
theory](http://wiki.c2.com/?WaterbedTheory) at work.
theory](https://wiki.c2.com/?WaterbedTheory) at work.

Adding support for reliable, ordered delivery of datagrams will allow
for any application to make use of reliable service simply by requesting
Expand Down Expand Up @@ -66,7 +66,7 @@ Link Layer
----------

The link layer, in a nutshell, is PPP with custom framing. The entirety
of [RFC 1661](https://tools.ietf.org/html/rfc1661) is normative, except
of [RFC 1661](https://datatracker.ietf.org/doc/html/rfc1661) is normative, except
as noted in this document.

### Encapsulation
Expand Down Expand Up @@ -102,12 +102,12 @@ Flag sequences constitute and empty frame, which is silently discarded.
The Protocol field is used as prescribed by RFC 1661, Section 2. PPP
assigned protocol numbers and their respective assigned protocols should
be used wherever it makes sense. Custom protocols must not be assigned
protocol numbers which overlap any [existing PPP assigned protocol](http://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml).
protocol numbers which overlap any [existing PPP assigned protocol](https://www.iana.org/assignments/ppp-numbers).

#### Frame Check Sequence field

The Frame Check Sequence is transmitted least significant octet first.
The check sequence is calculated using the [CRC-32](http://reveng.sourceforge.net/crc-catalogue/all.htm#crc.cat.crc-32)
The check sequence is calculated using the [CRC-32](https://reveng.sourceforge.net/crc-catalogue/all.htm#crc.cat.crc-32)
checksum. The parameters of the CRC algorithm are:

width=32 poly=0x04c11db7 init=0xffffffff refin=true refout=true
Expand Down Expand Up @@ -404,14 +404,14 @@ Useful Links
which includes a draft of this documentation along with a lot of
notes about the design decisions.
- [Python implementation of PULSEv2](https://github.com/coredevices/PebbleOS/tree/main/tools/libs/pulse2)
- [RFC 1661 - The Point to Point Protocol (PPP)](https://tools.ietf.org/html/rfc1661)
- [RFC 1662 - PPP in HDLC-like Framing](https://tools.ietf.org/html/rfc1662)
- [RFC 1663 - PPP Reliable Transmission](https://tools.ietf.org/html/rfc1663)
- [RFC 1570 - PPP LCP Extensions](https://tools.ietf.org/html/rfc1570)
- [RFC 2153 - PPP Vendor Extensions](https://tools.ietf.org/html/rfc2153)
- [RFC 3772 - Point-to-Point Protocol (PPP) Vendor Protocol](https://tools.ietf.org/html/rfc3772)
- [PPP Consistent Overhead Byte Stuffing (COBS)](https://tools.ietf.org/html/draft-ietf-pppext-cobs)
- [RFC 1661 - The Point to Point Protocol (PPP)](https://datatracker.ietf.org/doc/html/rfc1661)
- [RFC 1662 - PPP in HDLC-like Framing](https://datatracker.ietf.org/doc/html/rfc1662)
- [RFC 1663 - PPP Reliable Transmission](https://datatracker.ietf.org/doc/html/rfc1663)
- [RFC 1570 - PPP LCP Extensions](https://datatracker.ietf.org/doc/html/rfc1570)
- [RFC 2153 - PPP Vendor Extensions](https://datatracker.ietf.org/doc/html/rfc2153)
- [RFC 3772 - Point-to-Point Protocol (PPP) Vendor Protocol](https://datatracker.ietf.org/doc/html/rfc3772)
- [PPP Consistent Overhead Byte Stuffing (COBS)](https://datatracker.ietf.org/doc/html/draft-ietf-pppext-cobs)
- [ITU-T Recommendation X.25](https://www.itu.int/rec/T-REC-X.25-199610-I/en)
Comment thread
nschonni marked this conversation as resolved.
- [Digital Data Communications Message Protocol](http://www.ibiblio.org/pub/historic-linux/early-ports/Mips/doc/DEC/ddcmp-4.1.txt)
- [Digital Data Communications Message Protocol](https://www.ibiblio.org/pub/historic-linux/early-ports/Mips/doc/DEC/ddcmp-4.1.txt)

<!-- vim: set tw=72: -->