Answers to the "Please send back" list

Prepared 3 Nov 2026. Everything below was fetched or run in this session. Where I could not confirm something it says UNKNOWN. I contacted nobody and applied for nothing.

Short version

1. Weather source for C

Today's volume

I queried the production database read-only (railway ssh, table scan_analyses, which holds one analysis snapshot per scan):

First row in the table is 28 Jul 2026. A scan with no stored snapshot is not counted. I plan on about 500 a month today and 5,000 at 10x.

Sources compared

The pick

1. Open-Meteo paid plan for wind, gusts, direction and sea level, worldwide. Reasons: no delay on the IFS and Historical Forecast data, so a scan taken today works; one API for the past and the forecast needed in J; regional models down to 1.5 to 2 km in the UK and Europe.
2. NOAA NDBC and CO-OPS as real-reading overrides in the US, only when a station is within 10 km and closer than the model grid point. Tag these estimate with the station name and distance, as you specified.
3. Tide height and current outside the US: use the Open-Meteo marine values, labelled "≈" and "model". Real UK and Australian gauges need licence work first (UNKNOWN).
4. Australasia wind: weak spot. The only BOM model in Open-Meteo's historical set is 15 km and stale. Use the global IFS 9 km there until we find a real source.

Price

• Open-Meteo's pricing page shows plan names and call budgets only: Standard 1M calls a month, Professional 5M. It lists no dollar prices.
• Their own blog (12 Jun 2023) gives Standard $29 a month, Professional $99 a month. That is three years old; treat it as a guide.
• Their FAQ says Historical needs Professional. Whether the Historical Forecast API is covered by Standard is UNKNOWN. Someone should email info@open-meteo.com (you suggested this). I did not.
• The free tier is explicitly non-commercial (subscriptions or ads count as commercial). Data is CC BY 4.0, so we must credit them.

Monthly cost estimate

Assume at most 3 calls per scan (wind, marine, one extra), no cache hits.

Even if every call counted ten times against the budget, 150,000 is far below 1M. Caching by 0.1° cell and hour only trims this further. NOAA adds $0. J's forecast lookups add calls but stay small at this scale.

Error test plan

1. Build the reference set: scans that already have real wind from instruments, a log, or the Kimi photo reader. I have not counted how many exist (UNKNOWN); the first step is counting them.
2. For each, run C as if the real number were missing. Use the data as it would have been at scan time.
3. Record: speed error in knots, direction error as the smaller angle (0 to 180°), gust error.
4. Report the median and 90th percentile, split three ways: buoy vs model; by venue; by wind band. Show the number of scans in every cell. Under 20 scans, print "too few" rather than a number.
5. Head-to-head: where a scan has both a buoy and the model, compare each against the real reading.
6. Rule for direction: if a venue's median direction error exceeds 20°, or more than a quarter of its scans are over 20° out (starting thresholds, for you to tune), show speed only there.

2. Expedition live UDP format

Official channel list: not found in any source I read.

What the sources actually say:

The other numbers in the forum examples (2, 3, 13, 15, 17, 18, 50, 51) are unlabelled. I will not guess what they mean. The handoff's TWS, TWA, heel and others are therefore UNKNOWN by number.

A way around the missing list. The manual says a third party can send #S,GETCHANNELNAME,channel*xx and Expedition replies #S,CHANNELNAME,channel,name,shortname*xx. That could give the exact names at runtime. It means sending a command, which is more than the "read-only first" plan. Please decide.

Checksum rule. The manual does not state the algorithm. I tested a guess on the four examples I had (two from the forum, #G,12.34*62 and #G,-1.0*4A from the manual). XOR of every character from the # up to, not including, the *, shown as two uppercase hex digits matched all four. Leaving out the # matched none. This is my check, not an Expedition statement. Confirm with Nick White.

The manual also says Expedition's port can be 1024 to 65535 and broadcast should use the real subnet address (for example 192.168.0.255) rather than 255.255.255.255, because some routers block the latter.

3. Event list export and sail changes over UDP (G)

Needed from Nick White: event table name and columns, how the sail id maps to a name, and how users export events.

4. Regatta calendar sources (J)

Recommendation. Do not wait for an API. 1. Keep our own events table: class, name, dates, venue, latitude and longitude, source link, "confirmed" flag. 2. Seed it by hand for the target classes. That is a small list per class per year. 3. Import the J/70 feed automatically. Add small readers for other classes only if the hand list becomes a chore. 4. Match a scan by date and distance from the venue, with one day of slack because sources disagree. The one-tap "Racing at...?" confirm then covers errors. 5. Someone (not me) can ask Manage2Sail and Regatta Network whether they offer a feed.

5. Apple multicast entitlement and Android

• Apple: the entitlement is com.apple.developer.networking.multicast. Apple's page for it says it needs Apple's permission, requested through the "Multicast Networking Entitlement Request" form. The form is behind Apple sign-in; I could not open it. I could not read the entitlement doc page body.
• Who submits: UNKNOWN from sources. Apple does not say it has to be the Account Holder. The app belongs to the Sail Team LLC team (N5H73D2WDR, Account Holder Alex Higby per the repo notes), so Alex's login is the safe route. One forum report says the form asked for an App Store URL; our app is already in the store.
• Wait: no official figure. Developer reports in Apple's forums: about 5 business days, 3 days, "2 weeks and still waiting". Plan for 1 to 3 weeks.
• Status: not submitted. This needs Alex to submit or approve me doing it.
• Android: WifiManager.MulticastLock. Android's docs say the Wi-Fi stack normally filters packets not addressed to the device. A lock lets them through but "can cause a noticeable battery drain", so take it only while listening. It releases when the app exits or crashes. The permission name (CHANGE_WIFI_MULTICAST_STATE) was not on the page I fetched; confirm when building.
• Whether plain broadcast (x.x.x.255) needs the entitlement on iOS: assumed yes per your note, not verified. Test on a device.

6. Time estimates (working days, one developer)

What I saw in the repo that drives these: - Server: Express with SQLite (better-sqlite3). instrumentData.js accepts 15 numeric fields but has no source tags per value. No weather lookups exist (one file mentions the word). Logs, replay, Sail Team 6 inventory, sail life and Boom Cam routes exist (routes/logs.js is 563 lines). - Web: desktop/ with feature flags, plus server-side per-user flags in userFeatures.js. This fits "off except Alex". - Phone: Expo 54, React Native 0.81, expo-camera, expo-location, expo-network, expo-device. No UDP, motion-sensor, NFC or sun-position package is in package.json (I checked). A needs a new native module and a new native build.

Ranges are my judgment from the code I read, not measured. They do not include privacy-policy and App Store label work, or review time on your side.

Open questions for you

1. May I ask Open-Meteo for current prices and Historical Forecast coverage? (Not done.)
2. May Alex submit the Apple entitlement request, or should I prepare the text for him?
3. Who asks Nick White: the channel list, the event table, sail changes over UDP?
4. Send #S,GETCHANNELNAME queries to Expedition, or stay strictly read-only?